Azure для специалистов по Google Cloud

Эта статья поможет специалистам по Google Cloud получить представление об учетных записях, платформе и службах Microsoft Azure. Кроме того, в ней описаны основные общие черты и различия между платформами Google Cloud и Azure. (Обратите внимание, что прежнее название Google Cloud — Google Cloud Platform (GCP).)

Вы узнаете:

• как организованы учетные записи и ресурсы в Azure;
• как структурированы решения в Azure;
• чем основные службы Azure отличаются от служб Google Cloud.

В течение долгого времени Azure и Google Cloud развивались независимо друг от друга. Поэтому между ними есть важные различия в реализации и разработке решений.

Обзор Azure для Google Cloud

Как и Google Cloud, платформа Microsoft Azure основана на базовом наборе служб вычислений, хранилища, баз данных и сетевых служб. Во многих случаях обе платформы предоставляют эквивалентные продукты и службы. И Google Cloud, и Azure позволяют создавать решения высокого уровня доступности на основе узлов Linux или Windows. Если вы привыкли выполнять разработку с помощью Linux и технологии OSS, подходят обе платформы.

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

Управление учетными записями и подпиской

В Azure существует иерархия группы управления, подписок и групп ресурсов, обеспечивающая эффективное управление ресурсами. Это похоже на иерархию папок и проектов для ресурсов в Google Cloud.

Область действия уровней управления в Azure

• Группы управления: эти группы — это контейнеры, которые помогают управлять доступом, политикой и соответствием для нескольких подписок. Все подписки в группе управления автоматически наследуют условия, применяемые к группе управления.
• Подписки: подписка логически связывает учетные записи пользователей и ресурсы, созданные этими учетными записями пользователей. Для каждой подписки есть ограничения или квоты на объем создаваемых и используемых ресурсов. Организации могут использовать подписки для управления затратами и ресурсами, которые созданы пользователями, командами или проектами.
• Группы ресурсов: группа ресурсов — это логический контейнер, в котором развертываются и управляются ресурсы Azure, такие как веб-приложения, базы данных и учетные записи хранения.
• Ресурсы. Ресурсы — это экземпляры служб, создаваемых, например виртуальных машин, хранилищ или баз данных SQL.

Для служб Azure предусмотрено несколько вариантов тарификации. Можно подобрать подходящий тариф в соответствии с размером и потребностями организации. Дополнительные сведения см. на странице с обзором цен.

Подписки Azure — это группы ресурсов с назначенным владельцем, который отвечает за управление счетами и разрешениями.

Проект Google Cloud концептуально похож на подписку Azure с точки зрения выставления счетов, квот и ограничений. Однако с функциональной точки зрения проект Google Cloud больше похож на группу ресурсов в Azure. Это логическая единица, в которой развертываются облачные ресурсы.

Обратите внимание, что в отличие от Google Cloud, нет максимального количества подписок Azure. Каждая подписка Azure связана с одним клиентом Microsoft Entra (учетной записью в google Cloud). Клиент Microsoft Entra может содержать неограниченное количество подписок, в то время как Google Cloud имеет ограничение по умолчанию в 30 проектов на учетную запись.

Подпискам назначаются три типа учетных записей администратора:

• Администратор учетной записи. Владелец подписки и пользователь учетной записи, которому выставляются счета за использование ресурсов в подписке. Администратора учетной записи можно изменить, только передав права владения подпиской.
• Администратор служб. Эта учетная запись предоставляет права на создание ресурсов в подписке и управление ими, но не охватывает выставление счетов. По умолчанию администратору учетной записи и администратору служб назначается одна и та же учетная запись. Администратор учетной записи может назначить отдельному пользователю учетную запись администратора, чтобы он мог управлять техническими и рабочими аспектами подписки. Для каждой подписки можно назначить только одного администратора служб.
• Соадминистратор. Для каждой подписки можно назначить несколько учетных записей соадминистратора. Соадминистраторы не могут изменить администратора служб, но имеют полный контроль над ресурсами и пользователями подписки.

Для детального управления доступом к ресурсам Azure вы можете использовать механизм управления доступом на основе ролей Azure (Azure RBAC), охватывающий более 70 встроенных ролей. Вы также можете создавать собственные настраиваемые роли.

На более низком уровне роли и отдельные разрешения пользователей также можно назначить определенным ресурсам. В Azure все учетные записи пользователей связаны с учетной записью Майкрософт или учетной записью организации (учетной записью, управляемой с помощью идентификатора Microsoft Entra).

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

См. также

• Добавление или изменение ролей администратора Azure.
• Как скачать счет на оплату и данные о ежедневном потреблении ресурсов Azure

Управление ресурсами

Термин "ресурс" в Azure означает любой вычислительный экземпляр, объект хранилища, сетевое устройство или другую сущность, которую можно создать или настроить на платформе.

Ресурсы Azure развертываются и управляются с помощью одной из двух моделей: Azure Resource Manager или более ранней классической модели развертывания Azure. Все новые ресурсы создаются с помощью модели Resource Manager.

Группы ресурсов

Кроме того, в Azure есть сущности, которые называются группами ресурсов. В них упорядочиваются ресурсы, такие как виртуальные машины, хранилище и виртуальные сетевые устройства. Ресурс Azure всегда связан с одной группой ресурсов. Ресурс, созданный в одной группе, можно переместить в другую. Но он не может присутствовать в нескольких группах ресурсов одновременно. Дополнительные сведения см. в статьеПеремещение ресурсов Azure между группами ресурсов, подписками или регионами. Группы ресурсов — это основные группы, используемые в Azure Resource Manager.

Кроме того, ресурсы можно упорядочить с помощью тегов. Теги — это пары "ключ — значение", которые позволяют группировать ресурсы в подписке независимо от членства в группе ресурсов.

Интерфейсы управления

Azure предоставляет несколько способов управления ресурсами:

• Веб-интерфейс. Портал Azure предоставляет полнофункциональный веб-интерфейс управления для ресурсов Azure.
• REST API. REST API Azure Resource Manager предоставляет программный доступ к большинству функций на портале Azure.
• Командная строка. Средство Azure CLI предоставляет интерфейс командной строки для создания ресурсов Azure и управления ими. Интерфейс Azure CLI доступен для Windows, Linux и macOS.
• PowerShell. Модули Azure для PowerShell позволяют выполнять автоматизированные задачи управления с помощью скриптов. Модули PowerShell доступны для Windows, Linux и macOS.
• Шаблоны. Шаблоны Azure Resource Manager предоставляют возможности управления ресурсами на основе шаблонов JSON.
• Пакет SDK. Пакеты SDK — это коллекция библиотек, которые позволяют пользователям управлять службами Azure и взаимодействовать с ними программными средствами.

В каждом из этих интерфейсов группа ресурсов определяет, как создаются, развертываются или изменяются ресурсы Azure.

Кроме того, многие средства управления сторонних производителей, такие как Terraform от Hashicorp и Netflix Spinnaker, также доступны в Azure.

См. также

• Рекомендации по группам ресурсов Azure.

Регионы и зоны доступности

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

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

В Google Cloud регион включает как минимум две зоны доступности. Зона доступности соответствует физически изолированному центру обработки данных в географическом регионе. В Azure есть ряд средств для обеспечения избыточности приложений на каждом уровне потенциального сбоя, включая группы доступности, зоны доступности и парные регионы.

Все эти варианты описаны в следующей таблице.

Группы доступности

Для защиты от локальных аппаратных сбоев, например сбоя диска или сетевого коммутатора, разверните две или более виртуальных машин в группе доступности. Группа доступности состоит из двух или более доменов сбоя, которые совместно используют общие источники питания и сетевые коммутаторы. Виртуальные машины в наборе доступности распределены между доменами сбоя. Поэтому если аппаратный сбой влияет на один домен сбоя, сетевой трафик по-прежнему будет перенаправлять виртуальные машины в другие домены сбоя. Дополнительные сведения о группах доступности см. в статье Управление доступностью виртуальных машин Windows в Azure.

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

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

Группы доступности

зоны доступности;

Как и в регионах Google Cloud, в регионах Azure могут быть зоны доступности. Зона доступности — это физически изолированная зона в пределах региона Azure. У каждой зоны доступности есть отдельный источник питания, сеть и система охлаждения. Развертывание виртуальных машин между зонами доступности помогает защитить приложения от сбоев в центре обработки данных.

Развертывание избыточной в пределах зоны виртуальной машины в Azure

Дополнительные сведения см. в статье " Рекомендации по использованию зон доступности и регионов".

Пары регионов

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

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

Для геоизбыточного хранилища Azure автоматически выполняется резервное копирование в соответствующем регионе из пары. Для всех остальных ресурсов создание полностью избыточного решения с использованием пары регионов означает создание полной копии решения в обоих регионах.

Пары регионов в Azure

См. также

• Регионы размещения виртуальных машин в Azure
• Варианты доступности виртуальных машин в Azure
• Обеспечение высокого уровня доступности для приложений Azure
• Восстановление после сбоев и аварийное восстановление для приложений Azure
• Плановое обслуживание виртуальных машин Linux в Azure

Службы

Для получения наглядных сведений см. сравнение служб Google Cloud и Azure, в котором сопоставлены службы, представленные на этих двух платформах.

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

Следующие шаги

• Начало работы с Azure
• Эталонная архитектура Azure.