Google разрешил иметь виртуальным машинам в облаке Google Cloud Platform (GCP) до восьми виртуальных сетевых адаптеров.
Интерфейс виртуальных сетей в облаке GCP позволяет создавать множество внутренних виртуальных сетей, включая виртуальные сетевые экраны (Firewall) между ними, средствами самого облака Google, т.е. без использования дополнительных виртуальных машин.
Использование штатных средств GCP крайне практично, намного дешевле, а главное надёжнее, чем собственная сетевая среда, т.к. изначально защищает от DDoS атак не с помощью ваших денег на дополнительные мощности для вашей виртуальной машины сетевого экрана, а путём нагрузки на фильтр приложений самого Google.
Тем не менее, существуют организации, которые размещают все свои виртуальные машины в Google не потому, что это самое защищённое облако, а просто потому, что там самые дешёвые тарифы среди всех основных облачных провайдеров. Такие организации, хотят съэкономить на железных серверах, ничего не меняя в подходе к построению своей внутренней сети, простым механическим перемещением всех существующих серверов из локального датацентра в облако Google, при этом иногда даже не доверяя средствам безопасности Google.
Специально для такого случая предусмотрена функция "прямой провод" в Google, единственная в мире вложенная виртуализация виртуальных машин, а теперь ещё увеличено до восьми количество виртуальных сетевых адаптеров, которые вы можете создать внутри каждой виртуальной машины в облаке Google.
Таким образом, вы теперь можете реализовать сетевую схему, состоящую из виртуальных машин в защищённой даже от ваших корпоративных пользователей подсети, находящейся за вашим собственным сетевым экраном второго уровня, внутри виртуальной сети кластера, расположенного на ваших собственных виртуальных машинах, находящихся за вашим собственным сетевым экраном первого уровня, внутри виртуальныой сети облака, находящегося за сетевым экраном Google нулевого уровня, в облаке, которое построил Google.
В упрощённом варианте эту множественную вложенность можно пояснить на следующим практическом примере:
"Берёте любой зоопарк виртуальных машин с множеством вложенных подсетей со своего внутреннего кластера VMware, Hyper-V или XenServer и кладёте его целиком, включая сами сервера виртуализации, в облако Google, как есть, ничего не меняя. И продолжаете пользоваться, как и раньше."
Такой подход обеспечивает возможность безусловной миграции в облако Google любых, самых замороченных с точки зрения ИТ предприятий. Однако, если вы являетесь системным администратором на таком предприятии, то стоит понимать, что этот ленивый подход, когда можно просто буквально всё скопировать в облако Google, ничего не меняя, будет стоить дополнительных денег, так как тарифы при использовании штатных средств виртуализации и виртуальных сетей Google значительно дешевле, чем вы заплатите, в случае бесполезного использования вашего кластера виртуализации внутри виртуального облака Google, ввиду того, что нагрузка самих ваши виртуальных хост машин для виртуализации гостевых машин также будет тарифицироваться.
В этой связи, тем системным администраторам, которые хотят сябя проявить и съэкономить организации много денег, рекомендую хотя бы поверхностно изучить консоль администрирования Google Cloud Platform, чтобы начать миграцию не путём тупого копирования всей инфраструктуры, а путём плавного перевода внутренних виртуальных сетей, на виртуальные сети облака Goolge, а если что в процессе будет непонятно, то в процессе и после миграции Google вам поможет, причём сильно дешевле, чем обойдётся постоянно действующая прослойка виртуализации.
Напротив, в случае, если после переноса в облако Google, вы оставите всё как есть, то и эксплуатировать это всё будете сами, т.к. Google не имеет доступ внутрь вашей вложенной сети виртуализации и даже врядли захочет с ней разбираться, если вы сами датите им административный пароль, так как в роль технической поддержки Google совсем не входит техническая поддержка вашего кластера VMware и всего того, что внутри него. Они точно знают и поддерживают только свою собственную виртуализацию (нулевой уровень) и все сервисы, обеспечивающие её функционирование, включая настройку сетевых экранов и виртуальных сетей Google для ваших вложенных подсетей, но не сетевых экранов и виртуальных сетей внутри какой-то иной системы виртуализации, которую вы скопировали внутрь облака Google, возможно за исключением Linux KVM, который они точно поддерживают.
Комментариев нет:
Отправить комментарий