Bir neçə Google Cloud layihəsi, bir hibrid VPN? Əvvəlcə qərar verin
Ortaq VPC, peering və əlaqə mərkəzi müxtəlif sahiblik suallarına cavab verir. Hər layihə üçün bir VPN yerləşdirməzdən əvvəl şəbəkə sərhədini seçin.
Bir neçə Google Cloud layihəsi hibrid girişə ehtiyac duyduqda instinkt hər layihə üçün bir VPN-dir və bu, demək olar ki, həmişə yanlış formadır. Layihə sahibliyi və paket marşrutlaşdırması əlaqəli, lakin fərqli məsələlərdir və faydalı arxitektura sizə lazım olan inzibati sərhədləri saxlayaraq nəzərdə tutulan prefikslərə ofisə və ya məlumat mərkəzinə bir məqsədli yol verir. Bu yoxlamalar hansı şəbəkə modelini həqiqətən istədiyinizi, təkrar işdən qaçan ardıcıllıqla müəyyən edir. Hər biri müzakirəni erkən bitirə bilər və məqsəd də budur.
Layihə sərhədi avtomatik olaraq öz tunelini tələb etmir.
Ortaq obyektin şəbəkə olub-olmadığını yoxlayın
Sahiblik, yoxsa əlaqə haqqında sualla başlayın: mərkəzi şəbəkə sahibliyi bu iş yüklərini dəstəkləyə bilərmi? Cavab bəlidirsə və təşkilatın uyğun konfiqurasiyası varsa, host layihə VPC-yə, alt şəbəkələrə və əlaqəyə sahib olur, xidmət layihələri isə öz tətbiq resurslarına sahib olur. O ortaq şəbəkədə bir Cloud VPN bağlantısı sonra nəzərdə tutulan iş yükü prefikslərinə xidmət edə bilər, marşrutlaşdırma və təhlükəsizlik siyasətinə uyğun olaraq .
Birləşmənin nə etdiyi barədə dəqiq olun. Xidmət layihəsinin qoşulması onun mövcud müstəqil VPC-sini host şəbəkəsinə birləşdirmir və hər resursu avtomatik köçürmür. İş yükünün qoşulması, icazələr, ünvan məkanı və DNS arxitekturanın bir hissəsidir, parametrin nəticəsi deyil. Birləşməni əvvəlcə icazə dəyişikliyi, sonra marşrutlaşdırma dəyişikliyi kimi oxuyun, çünki komandalar fərqi adətən keçid zamanı kəşf edir.
Mərkəzi sahiblik maraqlı komandalar üçün qəbuledilməzdirsə, burada dayanın və qalanı peering və ya hub dizaynı kimi qəbul edin. Shared VPC-ni müstəqil şəbəkə həyat dövrlərinə ehtiyac duyan qrupa məcburi qəbul etdirmək texniki adı olan siyasi problem yaradır.
Müstəqil VPC-lərin müstəqil qala biləcəyini yoxlayın
Peering ayrı VPC-ləri qoruyur və buna görə də öz ünvan planlarını və öz dəyişiklik nəzarətini istəyən komandaları cəlb edir. İncə məqam peeringin keçidli olmamasıdır: A-dan B-yə və B-dən C-yə peering özlüyündə B vasitəsilə A-dan C-yə marşrut yaratmır. Üç layihə bir hibrid təyinat nöqtəsinə çatmalıdırsa, peeringlər zəncirinə deyil, məqsədli mübadilə planına ehtiyacınız var.
Hibrid çatımlılığın paylaşılması həm də sənədləşdirilmiş fərdi marşrut mübadiləsindən və nəzərdə tutulan Cloud Router elanlarından asılıdır. Peeringin aktiv statusu peeringin mövcud olduğunu sübut edir, hər tərəfin əhəmiyyət verdiyi prefikslərin ixrac edildiyini deyil. Peerin hər iki tərəfində ixrac edilən diapazonları, ixrac edən konfiqurasiyada yoxlayın və onları iş yüklərinizin həqiqətən istifadə etdiyi ünvanlarla müqayisə edin. Oradakı uyğunsuzluq peeringin sağlam görünməsinin, prefiksin isə çatılmaz qalmasının ən çox yayılmış səbəbidir.
Ünvan planını hər şeydən əvvəl yazın. Üst-üstə düşməyən diapazonlar, hər nəzərdə tutulan təyinat nöqtəsinə doğru marşrutlar və geri elanlar bu modelin yaşadığı və ya öldüyü üç artefaktdır.
Hub modelinin topologiyaya uyğun olub-olmadığını yoxlayın
Daha böyük və ya fərqli seqmentləşdirilmiş dizayn üçün Google-un Network Connectivity Center icmalı mərkəz və budaq modellərini təsvir edir. Onu diaqramın ima etdiyi üçün deyil, cari buraxılışın dəstəklədiyi üçün oxuyun: hansı VPC və hibrid kombinasiyaları, hansı marşrut ailələri və hər budaq növünün hansı siyasətlərə icazə verdiyi.
Ünvan ailəsini açıq şəkildə yoxlayın. Əksər bələdçilərdəki, o cümlədən bu bələdçidəki planlaşdırma nümunələri IPv4-ə aiddir və bir budaq növü üçün mövcud olan funksiya avtomatik olaraq digərinə dəyişmədən tətbiq olunmur. Əgər mühitiniz ikiqat yığımdırsa, bu sual sonrakı miqrasiyaya deyil, model seçiminə aiddir.
Aşağıdakı cədvəl üç modelin xülasəsi və hər birini həll edən sualdır.
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
Marşrutlaşdırmanın nəyi vermədiyini yoxlayın
Marşrut mübadiləsi etimadın ümumi verilməsi deyil. DNS həlli, firewall icazəsi və tətbiq avtorizasiyası öz məsuliyyətləri olaraq qalır və hər biri əksər təşkilatlarda fərqli sahib tərəfindən konfiqurasiya edilir. Çatımlılığın avtorizasiyanı nəzərdə tutduğunu fərz edən dizayn əlaqə testindən keçəcək və təhlükəsizlik yoxlamasından kəsiləcək.
Hər model üçün DNS hekayəsini də təsdiqləyin, çünki zona və yönləndirmə tənzimləmələri ortaq şəbəkə ilə peer şəbəkələr arasında fərqlənir. Bir layihədə həll olunan özəl adlar digərinə marşrutla keçmir.
Qərarı və onun sahibini qeyd edin
Təşkilatın ortaq şəbəkə sahibi istədiyi yerdə mərkəzləşdirin; həyat dövrü və ya siyasət tələb etdiyi yerdə ayrı VPC-ləri saxlayın. Sonra dəstəklənən əlaqə əlaqəsini seçin və hansını seçdiyinizi, ortaq şəbəkəyə kimin sahib olduğunu və hər layihənin nəyi elan etməsinə icazə verildiyini yazın.
Layihələri saymaq və hər biri üçün bir VPN almaq o sahiblik qərarının əvəzi deyil. Bu, hesabı və marşrut cədvəlini miras alan şəxsin sonradan verdiyi eyni qərardır.