Windows server azure что это



Windows Azure Pack — что за зверь и с чем его есть?

Всем согревающий привет от Лорда Огня!
В этот замечательный, солнечный и морозный (ух! — лад-хлад!) день уж очень хочется рассказать про что-нибудь облачное (банально, не правда ли? — смайл).
Вот как раз на тему облачности думаю я пора рассказать про такую интересную штуку как Windows Azure Pack! Это как WIndows Azure, только как-бы «у вас в кармане»! Интересно? Тогда милости прошу продолжить чтение!

Что за чудо-юдо, что за дивный зверь?

Ну давайте разберемся, что же это такое — Windows Azure Pack? Ну во-первых, он совершенно бесплатен и доступен для скачивания в открытую. Во-вторых, по сути это набор аналогичных технологий механизмов своего старщего и полноценного брата — Windows Azure, который является публичным облаком от Microsoft. Вот только Azure Pack надстраивается над частным облачным тандемом — Windows Server 2012 R2 и System Center 2012 R2. Надстройка же позволяет получить интерфейс внешне практически ничем не отличающийся от Windows Azure, реализуя возможности самообслуживания, мультитенантность (или многоарендность, если изволите) на разных уровнях предоставления услуг — как на уровне IaaS, так и на уровне PaaS.

Если вникнуть в детали — то по сути это набор веб-порталов, которые используют REST API и прослойку SPF (Service Provider Foundation) как его реализующую для управления различными элементами инфраструктуры: компонентами System Center, в частности VMM, базами данных SQL или MySQL, веб-сайтами IIS (по сути на уровне PaaS) — это как пример. Если полностью перечислить функционал — то получится следующая картина, описанная ниже.


Вот так выглядит полный список предоставляемых сервисов через Windows Azure Pack на сегодняшний день.

1) Портал управления для администраторов — по сути, интерфейс, через который производится вся настройка сервисов, которые можно будет предоставлять через Windows Azure Pack. В частности на этом портале создаются и управляются ресурсы частного из VMM (или же публичного облака — смотря кто конечный потребитель), учетные записи пользователей — по сути создается роль Tenant Administrator все в том же VMM, планы предоставления услуг (план — это набор услуг который можно скомпоновать и предоставить пользователю через создание подписки), задать квоты на потребляемые ресурсы, а также установить механизмы биллинга для потребляемых ресурсов за счет сторонних компонентов, например Cloud Cruiser.


Вот так выглядит созданный пользователь и проассоциированная с ним подписка в Windows Azure Pack с точки зрения VMM.

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

3) Service management API — это по сути REST API, который позволяет интегрировать порталы Windows Azure со сторонними решениями, например системами биллинга. Также этот механизм позволяет перенести функционал Windows Azure в кастомизированные, собственные веб-порталы (читай — интерфейсы). Тут главное разобраться — можно полностью реализовать весь функционал Windows Azure Pack на портале внешне ничего с ним общего даже не имеющим — да здравствует свобода выбора и конкурентное преимущество!

4) Виртуальные машины — по сути это уровень IaaS в области предоставления виртуальных машин как Windows, так и Linux. Данный портал включает в себя возможности создания галереи образов ВМ, аналогично своему взрослому брату, а также настройки виртуальных сетей и области масштабирования разворачиваемых компонентов.

5) Сервисная шина (Service Bus) — сервис, предоставляющий надежную систему обмена сообщениями и данными между распределенными приложениями. Данный механизм действует по подписке на сообщения на основе запросов или тем публикаций или подписок.

6) SQL и MySQL — по сути это сервис на уровне PaaS для предоставления экземпляров баз данных на указанных платформах, используется в сочетании с веб-сайтами, как правило. Тут важо понимать, что SQL можно и на уровне IaaS развернуть, т.е. получить виртуальную машину с СУБД, но в данном случае модно скзать, что предоставляется доступ к определенному экземпляру базы данных с квотой на ее объем, иными словами на ВМ с SQL может быть множество различных изолированных пользователей на уровне PaaS, который не имеют доступа к самой ВМ, только к СУБД, да и то — только к своему собственному экземпляру БД.


Пример подключения СУБД SQL на уровне PaaS в Windows Azure Pack.

7) Автоматизация и расширенные функции — по сути портал для создания кастомных, индивидуальных сервисов и их включение в работу пользователя. Можно, например, создавать runbook’и с целью автоматизации рабочих потоков и бизнес-процессов, а также исполнять их.

Где взять и как поставить?

Наверное, один из самых простых в установке продуктов из всех, с которыми мне приходилось работать.
Необходимо запустить наш Web Installer на машине, где планируется развернуть Azure Pack. Для начала рекомендую использовать экспресс-метод — это когда все роли и компоненты Azure Pack разворачиваются на одном сервере на базе Windows Server 2012 / 2012 R2.
Вот собственно и ссылка на установщик. Далее просто выбираем все компоненты и кликаем на Next->Next->Next>))))).


Так выглядит установщик Windows Azure Pack.

На всякий случай — список предварительных требований к установке:

• Windows Server 2012 или Windows Server 2012 R2

• Microsoft Web Platform Installer 4.6

• Microsoft .NET Framework 3.5 Service Pack (SP) 1

• Internet Information Services (IIS) 8 или IIS 8.5

• .NET Framework 4.5 Extended, with ASP.NET Windows 8

С точки зрения требования к оборудования картина такая:

• 8 ГБ ОЗУ. Если вы запускаете внутри ВМ, то настоятельно рекомендуется НЕ ИСПОЛЬЗОВАТЬ динамическую память.

• 40 ГБ дискового пространства.

По скольку Windows Azure Pack — это веб-портал, то по умолчанию понадобится доступ некоторым портам, на брандмауэре открыть их нужно будет:

Admin API (API функций администратора)
30004

Management portal for administrators (Портал управления для администраторов)
30091

Authentication site (Сайт аутентификации)
30071

Configuraton site (Сайт настройки и конфигурирования)
30101 — Локальная подсеть

Monitoring (Мониторинг)
30020

MySQL resource provider (Провайдер подключения СУБД MySQL)
30012

SQL Server or MySQL resource provider (Провайдер подключения СУБД SQL или MySQL)
30010

Tenant API (API для работы с пользовательскими функциями — внутренний)
30005

Tenant public API (API для работы с пользовательскими функциями — публичный)
30006

Management portal for tenants (Портал управления для пользователей)
30081

Usage (Служебный портал)
30022

WebAppGallery (Галерея веб-приложений)
30018

Windows authentication site (Сайт аутентификации)
30072

Как-то так выгляди общая история с WAP (Windows Azure Pack) — я естественно призываю самостоятельно попробовать его в деле, развернуть и настроить — а потом поиграть уже с сервисами и его функциями — крайне интересное занятие выходит на практике! Удачных Вам экспериментов!

Источник

Компоненты и границы информационной системы Azure

Эта статья содержит общее описание архитектуры Azure и управления. Среда системы Azure состоит из следующих сетей:

  • Рабочая сеть Microsoft Azure (сеть Azure).
  • Корпоративная сеть Майкрософт (корпоративная сеть).

За эксплуатацию и обслуживание этих сетей отвечают отдельные ИТ-специалисты.

Архитектура Azure

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

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

В слое узла виртуальных машин Azure запускается настроенная и защищенная последняя версия Windows Server. Azure использует версию Windows Server, которая включает в себя только компоненты, необходимые для размещения виртуальных машин. Это повышает производительность и уменьшает область атаки. Компьютерные границы устанавливаются гипервизором, который не зависит от безопасности операционной системы.

Управление Azure с помощью контроллеров структуры

В Azure виртуальные машины, работающие на физических серверах (колонки или узлы), группируются в кластеры примерно по 1000 объектов. Виртуальные машины независимо управляются программным компонентом избыточной и горизонтально масштабированной платформы, который называется контроллером структуры.

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

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

Инвентаризация оборудования

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

Образы операционной системы, управляемые контроллером структуры

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

Есть три типа образов операционной системы, управляемых контроллером структуры:

  • ОС узла: это настраиваемая операционная система, которая выполняется на узле виртуальных машин.
  • Собственная операционная система, которая выполняется на клиентах (например, в службе хранилища Azure). В этой операционной системе нет гипервизора.
  • Гость: гостевая ОС, которая выполняется на гостевых виртуальных машинах.

Собственные ОС и ОС узла, управляемые контроллером структуры, предназначены для использования в облаке и не являются общедоступными.

Собственная ОС и ОС узла

ОС узла и собственная ОС — это защищенные образы ОС, на которых размещены агенты структуры и которые запускаются на вычислительном узле (запускается как первая виртуальная машина на узле) и на узлах хранилища. Преимущество использования оптимизированных базовых образов ОС узла и собственной ОС заключается в уменьшении контактной зоны, предоставленной API-интерфейсами или неиспользуемыми компонентами. Это может привести к высоким рискам безопасности и увеличению объема памяти операционной системы. Сокращенные в объеме операционные системы включают только компоненты, необходимые для Azure.

Операционная система на виртуальной машине

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

Центры обработки данных Azure

Команда обслуживания и инфраструктуры Microsoft Cloud (MCIO) управляет центрами обработки данных и физической инфраструктурой для всех веб-служб Майкрософт. MCIO в основном отвечает за управление физическими элементами управления и элементами управления среды в центрах обработки данных, а также за контроль и поддержку внешних сетевых устройств (пограничные маршрутизаторы и маршрутизаторы центра обработки данных). MCIO также несет ответственность за настройку минимально возможного серверного оборудования на стойках в центре обработки данных. Клиенты не взаимодействуют с Azure напрямую.

Управление службой и группы обслуживания

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

Ниже приведены группы обслуживания:

  • Платформы приложений
  • Azure Active Directory
  • Служба вычислений Azure
  • Azure NET.
  • Службы проектирования облака.
  • ISSD: безопасность.
  • Многофакторная идентификация.
  • База данных SQL
  • Служба хранилища

Типы пользователей

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

Роль Внутренний или внешний Уровень конфиденциальности Авторизованные привилегии и выполняемые функции Тип доступа
Инженер центра обработки данных Azure Внутренние Отсутствие доступа к клиентским данным Управление физической безопасностью локальной среды. Проведение внутренних и внешних патрулирований центра обработки данных и отслеживание всех точек входа. Сопровождение некоторых сотрудников без допуска, которые предоставляют общие услуги (питание, уборка) или ИТ-услуги в центре обработки данных (сопровождение в центр обработки данных и из него). Систематический мониторинг и обслуживание сетевого оборудования. Управление инцидентами, замена или ремонт с помощью различных инструментов. Систематический мониторинг и обслуживание физического оборудования в центрах обработки данных. Доступ к среде по запросу владельцев. Возможность проводить судебные разбирательства, регистрировать отчеты об инцидентах и требовать обязательного обучения в сфере безопасности, а также соблюдения требований политики. Операционное владение и обслуживание критических инструментов безопасности, таких как сканеры и сбор данных журналов. Постоянный доступ к среде.
Рассмотрение инцидентов Azure (инженеры быстрого реагирования) Внутренние Доступ к клиентским данным Управление обменом данных между отделом обслуживания инфраструктуры, службой поддержки и группами инженеров. Рассмотрение инцидентов платформы, проблем с развертыванием и запросов на обслуживание. JIT-доступ к среде с ограниченным постоянным доступом к системам, неиспользуемым клиентами.
Инженеры по развертыванию Azure Внутренние Доступ к клиентским данным Выполнение развертывания и обновления компонентов платформы, программного обеспечения и запланированных изменений конфигурации в обслуживании Azure. JIT-доступ к среде с ограниченным постоянным доступом к системам, неиспользуемым клиентами.
Служба поддержки при клиентских сбоях Azure (клиент) Внутренние Доступ к клиентским данным Отладка и диагностика сбоев и ошибок платформы для отдельных вычислительных клиентов и учетных записей Azure. Анализ ошибок. Внедрение критически важных исправлений платформы или клиента, а также технических улучшений в службе поддержки. JIT-доступ к среде с ограниченным постоянным доступом к системам, неиспользуемым клиентами.
Инженеры инцидентов действующих сайтов Azure (инженеры по мониторингу) Внутренние Доступ к клиентским данным Диагностика работоспособности платформы и устранение рисков с помощью инструментов диагностики. Внедрение исправлений драйверов тома, восстановление компонентов после сбоев, поддержка по восстановлению после сбоев. JIT-доступ к среде с ограниченным постоянным доступом к системам, неиспользуемым клиентами.
Клиенты Azure Внешняя Н/Д Н/Д Н/Д

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

Внутренняя аутентификация Azure

Обмен данными между внутренними компонентами Azure защищен с помощью шифрования TLS. В большинстве случаев сертификаты X.509 являются самозаверяющими. Для сертификатов с подключениями, которые доступны за пределами сети Azure, а также сертификатов для контроллеров структуры применяются исключения. Контроллеры структуры имеют сертификаты, выданные центром сертификации Microsoft (ЦС) и поддерживаемые доверенным корневым ЦС. Это позволяет легко выпускать открытые ключи контроллера структуры. Кроме того, открытые ключи контроллера структуры используются инструментами разработчика Майкрософт, чтобы новые образы приложений при отправке разработчиками шифровались открытым ключом контроллера структуры для защиты любых внедренных секретов.

Аутентификация аппаратного устройства Azure

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

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

Сетевые устройства

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

Безопасное администрирование служб

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

Дальнейшие действия

Дополнительные сведения о действиях корпорации Майкрософт для защиты инфраструктуры Azure приведены в следующих статьях:

Источник

You may also like...

Adblock
detector