Что отличается, а что нет

Концепции облачных сетей пришли непосредственно из традиционных сетей дооблачной эры. В то же время облачные провайдеры должны решать все вопросы по организации своих огромных физических сетей, охватывающих весь земной шар, независимо от того, принадлежит ли их оптоволокно или арендовано.

Каждый облачный провайдер решает эти задачи по-своему. Это влияет на их функции или концепции более высокого уровня, поэтому, хотя все эти концепции пришли из традиционных сетей, детали их реализации различаются.

Google широко использует собственную программно-определяемую сеть Andromeda, которая не только позволяет GCP быстро настраивать и предоставлять новые облачные ресурсы, но также обеспечивает лучшую производительность сети.

AWS как пионерам облачных технологий часто обречены на использование более традиционных решений, что, несомненно, можно увидеть в сетевой структуре, а также они сталкиваются со всеми скрытыми препятствиями, которые впоследствии могут преодолеть конкуренты.

И прежде чем погрузиться в подробности, просто обычное заявление об отказе от ответственности, которое вы, вероятно, будете часто видеть при работе с облаком:

Поскольку и AWS, и GCP развиваются очень быстро, всегда возможно, что что-то новое было выпущено или изменено недавно или будет изменено очень скоро, поэтому всегда стоит перепроверить прямо в консоли - иногда даже официальная документация может быть устарело.

Сравнение сетевых продуктов и сервисов AWS и GCP

Регионы и зоны

Ресурсы и услуги обоих поставщиков облачных услуг размещены в разных местах по всему миру. И GCP, и AWS используют один и тот же термин «регион» для этих местоположений, что интуитивно понятно, поскольку «регион» - это не что иное, как географический регион, например us-west1, asia- east2, и так далее.

Регионы GCP:

Регионы AWS:

Для обоих облачных провайдеров регионы состоят из зон. В Google Cloud это просто «зона», а в AWS - «зона доступности» или сокращенно AZ. Зоны называются по региону, в котором они находятся, плюс одна дополнительная буква, чтобы отличать одну зону от другой, т. Е. us-west1-a, us-west1-b и т. Д.

Проще говоря, для тех, кто более знаком с инфраструктурой до облачной эпохи, вы можете думать, что «зона» - это не что иное, как центр обработки данных.

Является ли зона действительно просто центром обработки данных?

Что ж, это для AWS - как вы можете прочитать здесь, AWS AZ представляет собой один или несколько дискретных центров обработки данных.

Для Google Cloud все по-другому: зона размещена в одном или нескольких кластерах, как вы можете прочитать здесь. Таким образом, Google Cloud может иметь две или более зон в одном центре обработки данных, только в разных физических кластерах.

Например, регион Google Cloud europe-north1 называется Финляндия здесь, но есть только один дата-центр Google в Финляндии, недалеко от города Хамина. Это не оставляет нам выбора, кроме как предположить, что все зоны europe-north1 физически расположены там.

Для простоты можно предположить, что эта зона является просто центром обработки данных для обоих провайдеров.

Обычно по крайней мере три зоны размещаются в более или менее близлежащих местах, чтобы сформировать регион. Они соединены между собой с помощью избыточных каналов, благодаря чему достигается высокая доступность - в случае отказа одной зоны регион в целом выживет.

Есть одна хитрость с названиями зон. Как известно, зоны называются жилым районом плюс одна буква. Как в GCP, так и в AWS сопоставление имен зон с фактическими физическими зонами выполняется для каждого клиента. Это означает, что то, что для меня называется зоной us-west1-a, для вас может называться us-west1-b.

Уровни сетевых услуг

Одна вещь, которая уникальна для Google Cloud и отсутствует в AWS, - это уровни сетевых сервисов. Есть два уровня:

  • Стандартный уровень, который дешевле и обеспечивает «производительность, сопоставимую с другими общедоступными облаками», как заявляет Google.
  • Премиум-уровень, который включен по умолчанию, работает быстрее и достигается за счет максимально возможной маршрутизации трафика через самую обширную частную оптоволоконную сеть Google.

Подробнее об уровнях сети можно прочитать здесь.

Объем услуг

Некоторые службы являются глобальными, существуют в глобальном масштабе, в то время как другие привязаны к региону или даже к зоне и поэтому могут быть доступны не в каждом регионе - обычно процесс развертывания не простой и может занять некоторое время. чтобы данная услуга была доступна в каждом регионе.

Виртуальное частное облако

Виртуальное частное облако или VPC - это изолированная часть облака, в которой вы можете логически организовать все облачные ресурсы, привязанные к определенному проекту, отделу или любой другой группировке по вашему желанию.

С технической точки зрения VPC можно рассматривать как сеть, но сама сеть не является VPC. Виртуальное частное облако - это ваш частный пул ресурсов в общедоступном облаке.

На высоком уровне VPC похожи на AWS и Google Cloud, но при более внимательном рассмотрении можно найти интересные различия. VPC Google Cloud являются глобальными, при этом подсети внутри VPC являются зональными ресурсами, а в AWS VPC - региональными.

Фактически, когда вы создаете новый VCP в GCP, подсети во всех доступных регионах будут созданы для вас автоматически, но вы можете переключиться в ручной режим и определять подсети только для тех регионов, которые вам нужны.

Связь

И AWS, и GCP позволяют устанавливать сетевые подключения между VPC и внешними сетями, такими как локальные среды.

Я не буду вдаваться в подробности о продуктах для подключения к внешним сетям - я просто кратко перечислю их здесь, так как это очень конкретные варианты, которые интересны только крупным организациям. Конечно, у обоих провайдеров есть варианты для VPN, для подключения к VPC или возможность иметь высокоскоростное соединение с другими облачными сервисами (в отличие от подключения к ним через общедоступный Интернет).

Давайте подробнее рассмотрим пиринг и совместное использование VPC, так как он более полезен для массовой аудитории.

Пиринг и совместное использование VPC

И у GCP, и у AWS есть два продукта с почти одинаковыми названиями, предназначенные для аналогичных целей. Пиринг AWS VPC позволяет подключаться к VPC внутри или между аккаунтами AWS или регионами. Как и в случае с GCP, все VPC являются глобальными, и соединение между регионами не является проблемой. Аналогично названный VPC Network Peering позволяет устанавливать соединения между проектами GCP, независимо от того, принадлежат ли они одной и той же организации или между разными организациями.

Вместо однорангового соединения VPC можно также использовать общий VPC. С помощью GCP Shared VPC вы можете совместно использовать VPC между несколькими проектами и иметь централизованное администрирование и контроль, а с AWS Shared VPC несколько учетных записей могут использовать один и тот же VPC.

Балансировка нагрузки

Нельзя говорить о сети, не упомянув о балансировке нагрузки. И GCP, и AWS имеют все необходимое для настройки балансировки нагрузки для вашего приложения, но принцип, который они используют для определения своего продукта, отличается.

С AWS у вас есть два продукта, которые обычно используются в традиционных сетях: Балансировщик нагрузки приложений, который работает на уровне OSI 7, который представляет собой уровень приложения или HTTP (s), проще говоря, и Балансировщик сетевой нагрузки, который работает на уровне 4 OSI или транспортном уровне и может маршрутизировать трафик TCP, UDP или TLS. Оба балансировщика нагрузки могут работать с внутренним или внешним трафиком.

Документация по GCP Cloud Load Balancing наводит нас на мысль, что внутренний и внешний трафик будет балансироваться разными методами. Может быть, они действительно есть, глубоко внутри, но на самом деле в консоли GCP все очень похоже на AWS. У вас есть три варианта вместо двух: HTTP (s), TCP и SSL и UDP.

Настроить балансировщики нагрузки GCP легко, поскольку они скрывают некоторые технические детали, вероятно, из-за более эфемерного характера базовой сети Google. Например, при настройке целей для балансировки нагрузки вы можете просто выбрать группу экземпляров или группу конечных точек зональной сети. Но с AWS перед выбором целей вы должны вручную отметить все зоны и выбрать одну подсеть для каждой зоны, где расположены ваши цели, что делает балансировку нагрузки GCP более гибкой и простой.

Заключение

В целом сеть в GCP выглядит более гибкой и в целом лучше по сравнению с AWS, которая естественным образом эволюционировала из концепций и практик, существовавших до облачной эпохи.

В то же время в AWS есть все необходимое для работы в облаке и даже больше. Неважно, являетесь ли вы единственным человеком, небольшим стартапом или огромной компанией.

Преимущество GCP в сети в основном достигается благодаря программно-определяемой сетевой архитектуре Andromeda от Google, но иногда эта глобальная сеть является не чем иным, как хорошим маркетингом, UX и мудрой конфигурацией.

Ресурсы

AWS

GCP