AWS tək tunel bildirişi: həqiqətən nə vaxt əhəmiyyət daşıyır
Konfiqurasiya edilmiş ehtiyat peer iki istifadəyə yararlı tunel demək deyil. Qərarı sübutlara görə verin: nə işləyir, nə qədər sürətli və növbəti dəyişiklik nəyi pozur.
Bir tunelin söndüyünü bildirən AWS Health xəbərdarlığı adətən heç nə pozulmuş görünməyəndə gəlir. Buna görə də ona məhəl qoyulmur. Bildiriş kəsinti təsvir etmir; AWS-in müşahidə pəncərəsindən sonra davam edən ehtiyatlılıq vəziyyətini təsvir edir. Tədbir görüb-görməyəcəyiniz dizaynınızın nəyə dözə bilməsindən asılıdır, panelin necə görünməsindən deyil.
Bildiriş əslində nəyi ölçdü
Hər Site-to-Site bağlantısının müxtəlif AWS son nöqtələrində bitən iki tuneli var. AWS-in monitorinq sənədləri hər ikisinin ehtiyat üçün konfiqurasiya edilməsini tövsiyə edir və biri sənədləşdirilmiş müddət ərzində sönülü qaldıqda bildiriş yaradır. Bu müddət vacibdir, çünki qısa titrəmə və daimi itki bir qrafikdə eyni görünür.
Bağlantının ümumi vəziyyəti əvəzinə hər tunelin telemetriyasını oxuyun. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' hər tunel üçün status və mesaj qaytarır və bildirişin əsaslandığı sübut budur.
Cavabınızı müəyyən edən üç şərt
Bunun bilet, yoxsa laqeydlik olduğuna qərar verməzdən əvvəl üç şərti nəzərdən keçirin.
Birincisi, sağ qalan tunel yükü daşıya bilirmi, o cümlədən istənilən bufer həddi və elan etdiyi prefikslər? İkincisi, yaradıldığından bəri sönülü olan ikinci tunelin heç vaxt qalxdığı sübut olunmayıbsa, failover həqiqətən baş verirmi? Üçüncüsü, növbəti planlaşdırılmış dəyişikliyiniz hər iki tuneli eyni vaxtda söndürərmi və bununla kosmetik xəbərdarlığı texniki xidmət pəncərəsi probleminə çevirərmi? Hər hansı cavab xeyr və ya naməlumdursa, bildiriş real tapıntıdır.
Əgər hər üçü açıq şəkildə qaydasındadırsa, niyə dözümlü olduğunu yazın və davam edin. Bu qeyd gələn rübdəki mübahisədən daha dəyərlidir.
Ehtiyat peer nəyi sübut etmir
Konfiqurasiya edilmiş ehtiyat peer-i olan müştəri şlüzü AWS-in iki sağlam tunel gördüyünün sübutu deyil. Müştəri tərəfi yeni danışıq tələb edən soyuq peer saxlaya bilər və bu, qanuni dizayn ola bilər. Yenə də bu, iki canlı tunelin verdiyi müşahidə deyil.
İki fiziki marşrutlaşdırıcı da əks halı həll etmir. Hər iki tunel bir cihazda bitəndə və ya bir yuxarı keçiddən çıxanda ehtiyatlılıq yalnız kağız üzərində qalır.
Dəyişikliyi təsir radiusuna uyğunlaşdırın
AWS-in son nöqtələrin əvəzlənməsi sənədləri halları ayırır və bu fərqi diqqətdən qaçırmaq asandır. AWS tərəfindən idarə olunan yeniləmələr bir dəfəyə bir tunelə tətbiq edilir. Hədəf şlüzə, müştəri şlüzünə və ya bağlantı seçimlərinə müştərinin başlatdığı dəyişikliklər, əvəzedici son nöqtələr hazırlanarkən hər iki tuneli əlçatmaz edir.
Tək tuneldə seçimləri dəyişmək öz elan edilmiş təsiri olan üçüncü haldır: həmin tunel öz yeniləməsi zamanı əlçatmaz olur, digəri isə işləməyə davam edir.
Alternativi ona ehtiyac duymazdan əvvəl sübut edin
Hadisəni gözləmək əvəzinə testi planlaşdırın. Sağlam tuneli texniki xidmət pəncərəsi daxilində söndürün, alternativin danışıq apardığını təsdiqləyin, sonra real trafikin ondan hər iki istiqamətdə keçdiyini təsdiqləyin. Tunel statusu ilə yanaşı qayıdış marşrutlaşdırmasını da yoxlayın, çünki ikinci faza uyğunsuzluğu tuneli qaldırılmış saxlayır və iş yükünü öldürür. Keçidi də orada olarkən ölçün.
Bildirişi, telemetriya çıxışını və dəyişiklik planını bir qeyddə saxlayın. Bu qeyd gələn rübün bildirişini kimsə ehtiyatı sınaqdan keçiribmi-deyə mübahisə etmək əvəzinə iki dəqiqəlik baxışa çevirir.