Некалькі праектаў Google Cloud і адна гібрыдная VPN? Спачатку вырашыце
Агульная VPC, пеерынг і цэнтр злучэнняў адказваюць на розныя пытанні ўласнасці. Выберыце мяжу сеткі, перш чым разгортваць адну VPN на кожны праект.
Калі некалькі праектаў Google Cloud маюць патрэбу ў гібрыдным доступе, інстынкт падказвае адну VPN на праект, і гэта амаль заўсёды няправільная форма. Уласнасць праекта і маршрутызацыя пакетаў — звязаныя, але розныя пытанні, і карысная архітэктура захоўвае патрэбныя вам адміністрацыйныя межы, адначасова даючы меркаваным прэфіксам адзін прадуманы шлях да офіса або цэнтра апрацоўкі даных. Гэтыя праверкі вызначаюць, якую сеткавую мадэль вы насамрэч хочаце, у парадку, які пазбягае пераробак. Кожная з іх можа скончыць абмеркаванне раней, і ў гэтым сэнс.
Мяжа праекта не патрабуе аўтаматычна ўласнага тунеля.
Праверце, ці агульны аб'ект — гэта сетка
Пачніце з пытання пра ўласнасць, а не пра злучэнне: ці можа цэнтралізаваная ўласнасць сеткі падтрымаць гэтыя працоўныя нагрузкі? Калі адказ так і ў арганізацыі ёсць прыдатная канфігурацыя, хост-праект валодае VPC, падсеткамі і злучэннем, а сэрвісныя праекты валодаюць сваімі рэсурсамі праграм. Адно злучэнне Cloud VPN у гэтай агульнай сетцы можа затым абслугоўваць меркаваныя прэфіксы працоўных нагрузак, пры ўмове выканання палітык маршрутызацыі і бяспекі .
Будзьце дакладныя ў тым, што робіць далучэнне. Далучэнне сэрвіснага праекта не аб'ядноўвае яго існуючую незалежную VPC з хост-сеткай і не пераносіць аўтаматычна кожны рэсурс. Далучэнне працоўных нагрузак, дазволы, адрасная прастора і DNS — усё гэта частка архітэктуры, а не вынікі налады. Чытайце далучэнне спачатку як змяненне дазволаў, а потым як змяненне маршрутызацыі, бо каманды звычайна выяўляюць розніцу падчас пераходу.
Калі цэнтралізаваная ўласнасць непрымальная для задзейнічаных каманд, спыніцеся тут і разглядайце астатняе як праект пеерынгу або цэнтра. Прымусовае ўкараненне Shared VPC у групе, якой патрэбны незалежныя жыццёвыя цыклы сеткі, стварае палітычную праблему з тэхнічнай назвай.
Праверце, ці могуць незалежныя VPC заставацца незалежнымі
Пеерынг захоўвае асобныя VPC, і менавіта таму ён прыцягвае каманды, якія хочуць уласныя планы адрасоў і ўласны кантроль змен. Загваздка ў тым, што пеерынг не транзітыўны: пеерынг A-да-B і B-да-C сам па сабе не стварае маршрут A-да-C праз B. Калі тром праектам трэба дасягнуць адной гібрыднай мэты, патрэбны прадуманы план абмену, а не ланцуг пеерынгаў.
Абагульванне гібрыднай дасяжнасці таксама залежыць ад дакументаванага абмену карыстальніцкімі маршрутамі і ад меркаваных аб'яў Cloud Router. Статус пеерынгу «актыўны» даказвае, што пеерынг існуе, а не што прэфіксы, якія важныя кожнаму боку, былі экспартаваны. Праверце экспартаваныя дыяпазоны на абодвух баках пеера, у той канфігурацыі, якая выконвае экспарт, і параўнайце іх з адрасамі, якія вашы працоўныя нагрузкі фактычна выкарыстоўваюць. Няўзгодненасць там — самая частая прычына таго, што пеерынг выглядае здаровым, а прэфікс застаецца недасяжным.
Напішыце план адрасоў перш за ўсё. Дыяпазоны, што не перакрываюцца, маршруты да кожнай меркаванай мэты і зваротныя аб'явы — гэта тры артэфакты, на якіх гэтая мадэль жыве або памірае.
Праверце, ці падыходзіць мадэль цэнтра да тапалогіі
Для большага або інакш сегментаванага дызайну агляд Google Network Connectivity Center апісвае мадэлі цэнтра і промняў. Чытайце яго дзеля таго, што падтрымлівае бягучая версія, а не дзеля таго, што мяркуе дыяграма: якія камбінацыі VPC і гібрыдных злучэнняў, якія сем'і маршрутаў і якія палітыкі дазваляе кожны тып промня.
Праверце сямейства адрасоў яўна. Прыклады планавання ў большасці кіраўніцтваў, уключаючы гэтае, тычацца IPv4, а функцыя, якая існуе для аднаго тыпу промня, не абавязкова прымяняецца без змен да іншага. Калі ваша асяроддзе двухстэкавае, гэтае пытанне адносіцца да выбару мадэлі, а не да пазнейшай міграцыі.
Табліца ніжэй — гэта зводка трох мадэляў і пытання, якое вырашае кожную.
| 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? |
Праверце, чаго не дае маршрутызацыя
Абмен маршрутамі — не ўсеагульная выдача даверу. Развязанне DNS, дазвол файрвола і аўтарызацыя праграм застаюцца ўласнымі абавязкамі, і кожнае з іх у большасці арганізацый наладжвае розны ўладальнік. Дызайн, які мяркуе, што дасяжнасць азначае аўтарызацыю, пройдзе тэст злучэння і праваліць агляд бяспекі.
Пацвердзіце гісторыю DNS для кожнай мадэлі таксама, бо налады зон і перасылкі адрозніваюцца паміж агульнай сеткай і сеткамі з пеерынгом. Прыватныя імёны, якія развязваюцца ў адным праекце, не ідуць маршрутам у іншы.
Запішыце рашэнне і яго ўладальніка
Цэнтралізуйце там, дзе арганізацыя хоча агульнага ўладальніка сеткі; трымайце асобныя VPC там, дзе гэтага патрабуе жыццёвы цыкл або палітыка. Затым выберыце падтрымліванае злучэнне і запішыце, якое менавіта вы выбралі, хто валодае агульнай сеткай і што кожнаму праекту дазволена аб'яўляць.
Падлік праектаў і купля адной VPN на кожны не замяняе таго рашэння пра ўласнасць. Гэта тое ж рашэнне, прынятае пазней тым, хто атрымае ў спадчыну рахунак і табліцу маршрутызацыі.