AWS tek tünel bildirimi: gerçekte ne zaman önem taşır
Yapılandırılmış bir yedek peer, iki kullanılabilir tünelle aynı şey değildir. Kanıta dayanarak karar verin: ne devralıyor, ne kadar hızlı ve bir sonraki değişikliğiniz neyi kesiyor.
Bir tünelin kapalı olduğunu söyleyen AWS Health bildirimi genellikle hiçbir şey bozuk görünmediğinde gelir. Tam da bu yüzden yok sayılır. Bildirim bir kesintiyi değil, AWS'nin gözlem penceresini aşan bir yedeklilik durumunu anlatır. Harekete geçip geçmemeniz, tasarımınızın neye dayanabildiğine bağlıdır, panelin nasıl hissettirdiğine değil.
Bildirim gerçekte neyi ölçtü
Her Site-to-Site bağlantısının farklı AWS uç noktalarında sonlanan iki tüneli vardır. AWS'nin izleme belgeleri ikisinin de yedeklilik için yapılandırılmasını önerir ve biri belgelenen süre boyunca kapalı kalırsa bildirimi yükseltir. O süre önemlidir, çünkü kısa bir dalgalanma ile kalıcı kayıp tek bir grafikte aynı görünür.
Bağlantının genel durumu yerine tünel başına telemetriyi okuyun. aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123 --query 'VpnConnections[0].VgwTelemetry' her tünel için durum ve mesaj döndürür ve bildirimin dayandığı kanıt budur.
Yanıtınızı belirleyen üç koşul
Bunun bir bilet mi yoksa omuz silkmek mi olduğuna karar vermeden önce üçünü de gözden geçirin.
Birincisi, hayatta kalan tünel yükü taşıyabiliyor mu, olası bant genişliği tavanı ve duyurduğu önekler dahil? İkincisi, oluşturulduğundan beri kapalı olan ikinci tünelin hiçbir zaman açıldığı kanıtlanmadıysa, yük devri gerçekten oluyor mu? Üçüncüsü, bir sonraki planlı değişikliğiniz iki tüneli aynı anda kapatır mı, bu da kozmetik bir uyarıyı bakım penceresi sorununa dönüştürür. Herhangi bir yanıt hayır veya bilinmiyorsa, bildirim gerçek bir bulgudur.
Üçü de kanıtlanabilir şekilde iyiyse, neden katlanılabilir olduğunu yazın ve devam edin. O not, gelecek çeyrekteki tartışmadan daha değerlidir.
Yedek peer neyi kanıtlamaz
Yapılandırılmış yedek peer'i olan bir müşteri geçidi, AWS'nin iki sağlıklı tünel gördüğünün kanıtı değildir. Müşteri tarafı yeni bir müzakere gerektiren soğuk bir peer tutuyor olabilir ve bu meşru bir tasarım olabilir. Yine de bu, iki canlı tünelin gözlemi değildir.
İki fiziksel yönlendirici de ters durumu düzeltmez. İki tünel de tek bir cihazda sonlanıyor veya tek bir üst bağlantıdan çıkıyorsa, yedeklilik yalnızca kâğıt üzerinde vardır.
Değişikliği etki yarıçapına uygun hale getirin
AWS'nin uç nokta değiştirme belgesi belgesi durumları ayırır ve bu ayrımı gözden kaçırmak kolaydır. AWS tarafından yönetilen güncellemeler aynı anda tek tünele uygulanır. Müşteri tarafından başlatılan hedef geçit, müşteri geçidi veya bağlantı seçenekleri değişiklikleri, yedek uç noktalar hazırlanırken iki tüneli de kullanılamaz hale getirir.
Tek bir tünelde seçenek değiştirmek, kendi bildirilen etkisi olan üçüncü durumdur: o tünel kendi güncellemesi sırasında kullanılamaz ve diğeri çalışmaya devam eder.
Alternatifi ihtiyaç duymadan önce kanıtlayın
Olayı beklemek yerine testi planlayın. Sağlıklı tüneli bir bakım penceresi içinde düşürün, alternatifin müzakere ettiğini doğrulayın, ardından gerçek trafiğin iki yönde de ondan geçtiğini doğrulayın. Tünel durumunun yanı sıra dönüş yönlendirmesini de kontrol edin, çünkü ikinci faz uyuşmazlığı tüneli ayakta, iş yükünü ölü bırakır. Orada bulunduğunuz sırada geçiş süresini ölçün.
Bildirimi, telemetri çıktısını ve değişiklik planını tek bir kayıtta tutun. O kayıt, gelecek çeyreğin bildirimini birinin yedeği hiç test edip etmediği tartışması yerine iki dakikalık bir incelemeye dönüştürür.