Ümumi Transit Gateway: AWS RAM-da marşrutlar kimə aiddir

Transit Gateway-i Resource Access Manager ilə paylaşmaq bir konkret şey edir: başqa hesaba sahibi olmadığı resursa qarşı müəyyən qoşma API dəstini çağırmağa imkan verir. Bu, şlüzü, onun marşrut cədvəllərini və ya trafikin necə yönləndiriləcəyinə dair qərar hüququnu ötürmür. İnsanlar bunun əksini düşünür, çünki qoşma alıcının konsolunda görünür və dərhal işləyir, bu da sahiblik kimi hiss olunur. Altındakı mexanizm paylaşılan resursa verilən icazədir və hər uşaq obyekt sahibin hesab sərhədi daxilində qalır. Bu bölgü paylaşılan keçid ətrafındakı giriş-inkar biletlərinin çoxunu izah edir.

Paylaşım əslində nəyi həvalə edir

Resurs paylaşımı bir resursu, bir prinsipi və idarə olunan icazəni adlandırır. İcazə həmin prinsipin yerinə yetirə biləcəyi əməliyyatları sadalayır və Transit Gateway üçün bu siyahı paylaşılan resurs üzərində qoşma əməliyyatlarını əhatə edir.

Siyahıdan kənar hər şey konsolda deyil, API-də uğursuz olur, buna görə xəta çox vaxt skriptin ilk işə düşməsində görünür.

Marşrut cədvəlləri, əlaqələr və yayılmalar sahibdə qalır

Yönləndirmə üç uşaq obyektlə müəyyən edilir: qoşmanın hansı marşrut cədvəli ilə əlaqələndirildiyi, hansı cədvəllərə yayıldığı və həmin cədvəllərin hansı marşrutları saxladığı. AWS-in paylaşım sənədləri bildirir ki, alıcı paylaşım vasitəsilə transit gateway marşrut cədvəllərini və ya onların əlaqə və yayılmalarını yarada, dəyişdirə və ya silə bilməz. Həmin çağırışlar sahib hesaba aiddir. Yeni əlaqəyə ehtiyacı olan alıcı inzibati dəyişiklik istəyir, unutduğu icazəni tətbiq etmir.

Aşağıdakı cədvəl dizayn sənədlərinə yazdığım bölgüdür, çünki işçi dəyişikliklərindən sonra da qalır.

Orta sətri diqqətlə oxuyun: VPC sahibi öz subnet marşrutlarını, şlüz sahibi mərkəzi yönləndirmə qərarını idarə edir və işlək yol hər ikisini tələb edir. Heç bir hesab bunu təkbaşına tamamlaya bilməz.

Bir yol, iki hesab

Paketi spoke VPC-dən yerli prefiksə qədər izləyin. Spoke subnet marşrut cədvəli həmin prefiksi transit gateway qoşmasına göndərməlidir və bunu VPC sahibi dəyişə bilər. Sonra şlüzün qoşmanın əlaqəli cədvəlində VPN qoşmasına işarə edən marşrut olmalıdır və bunu yalnız sahib dəyişə bilər. Qayıdış trafiki hər ikisinin güzgüsünə ehtiyac duyur. Hər hansı tərəfi buraxın və yarım quraşdırılmış, firewall problemi kimi görünən bir yol alırsınız.

Hər iki dəyişikliyi iki təyin olunmuş şəxslə bir bilettə yazın, əks halda fərqli həftələrdə bitəcəklər.

Yerləşmə vacib olduqda Əlçatımlılıq Zonası ID-lərindən istifadə edin

Zona adları hesaba məxsus ləqəblərdir. us-east-1a bir hesabda digər hesabdakı us-east-1a ilə eyni fiziki zona olacağına zəmanət verilmir. Dizayn qoşma ilə iş yükünün eyni zonada olmasını tələb etdikdə AZ ID-lərini müqayisə edin və qeyd edin.

Adları müqayisə etmək düzgün görünən diaqram və düzgün olmayan gecikmə profili yaradır. Bunu diaqram hələ çəkilərkən yoxlayın, kimsə fərqi ölçdükdən sonra deyil.

Paylaşımı dayandırmaq məlumat yolunu kəsmir

Paylaşımı silmək ləğv kimi hiss olunur və bu dərhal trafik dayanması deyil. AWS sənədləşdirir ki, şlüz paylaşımdan çıxarıldıqda qoşma işlək qalır. Resursu idarə etmə icazəsi yox olur, mövcud qoşma isə kimsə onu silənə və ya söndürənə qədər yönləndirməyə davam edir. Ləğvi iki addım kimi planlaşdırın: paylaşımı silin, sonra qoşmanı silin, ikincisini sahib yerinə yetirsin.

Paylaşım yeganə nəzarətinizdirsə, nəzarətiniz yoxdur.

Paylaşım qeydini və marşrut qeydini birlikdə saxlayın

İki artefakt iki fərqli suala cavab verir. Paylaşım qeydi resursla kimin işləyə biləcəyini deyir. Marşrut cədvəlləri hansı şəbəkələrin həqiqətən danışa biləcəyini deyir. Onları eyni sahib siyahısı ilə birlikdə saxlayın, əks halda növbəti insident heç vaxt problem olmayan icazəni sübut edən biri ilə başlayır.

Sonra hər istiqamətdə bir axını və əlçatmaz qalmalı olan bir prefiksi yoxlayın.