azure stack hci что это
Обзор решения Azure Stack HCI
Область применения: Azure Stack ХЦИ, версии 21H2 и 20H2
Azure Stack хЦи — это решение кластера гиперконвергентном infrastructure (хЦи), в котором размещены виртуализированные рабочие нагрузки Windows и Linux и их хранилище в гибридной среде, объединяющей локальную инфраструктуру с облачными службами Azure.
Azure Stack ХЦИ предназначено как узел виртуализации, поэтому большинство приложений и ролей сервера должны выполняться внутри виртуальных машин. К исключениям относятся Hyper-V, сетевой контроллер и другие компоненты, необходимые для программно-определяемой сети (SDN), а также для управления и работоспособности размещенных виртуальных машин.
Azure Stack ХЦИ доставляется как служба Azure и оплачивается по подписке Azure. Гибридные службы Azure расширяют возможности кластера с помощью таких возможностей, как облачный мониторинг, Site Recovery и резервное копирование виртуальных машин, а также центральное представление всех Azure Stack развертываний ХЦИ в портал Azure. вы можете управлять кластером с помощью существующих средств, включая Windows центре администрирования и PowerShell.
Функции и архитектура Azure Stack ХЦИ
Azure Stack хЦи — это встроенный интегрированный стек виртуализации, построенный на основе проверенных технологий, которые уже развернуты в масштабе, включая Hyper-V, дисковые пространства Direct и SDN в Azure. Она входит в состав семейства Azure Stack, используя те же программно определяемые программные средства вычислений, хранения и сети, что и центр Azure Stack.
Просмотрите видео о возможностях Azure Stack ХЦИ на высоком уровне:
Каждый кластер Azure Stack ХЦИ состоит из двух и 16 физических, проверенных серверов. Кластеры серверов совместно используют общую конфигурацию и ресурсы, используя функцию отказоустойчивой кластеризации Windows Server.
Azure Stack ХЦИ объединяет следующее:
Зачем Azure Stack ХЦИ?
Существует множество причин, по которым клиенты могут выбрать Azure Stack ХЦИ, в том числе:
Распространенные варианты использования для Azure Stack ХЦИ
Клиенты часто выбирают Azure Stack ХЦИ в следующих сценариях.
| Вариант использования | Описание |
|---|---|
| Филиалы и пограничные задачи | Для рабочих нагрузок филиалов и пограничных задач можно снизить затраты на инфраструктуру, развернув кластеры с двумя узлами с незатратными вариантами слежения, такими как Cloud Witness или файловый ресурс-свидетель на основе USB. Другим фактором, влияющим на снижение стоимости кластеров с двумя узлами, является поддержка бескоммутаторных сетей, которая основывается на перекрестном кабеле между узлами кластера вместо более ресурсоемких коммутаторов высокой скорости. Клиенты также могут централизованно просматривать удаленные Azure Stack развертывания ХЦИ в портал Azure. Дополнительные сведения об этой рабочей нагрузке см. в статье Развертывание филиалов и пограничных приложений на Azure Stack хЦи. |
| Инфраструктура виртуальных рабочих столов (VDI) | Кластеры Azure Stack HCI хорошо подходят для крупномасштабных развертываний VDI с RDS или эквивалентных сторонних предложений в качестве брокера виртуальных рабочих столов. Azure Stack HCI предоставляет дополнительные преимущества, включая централизованное хранение и повышенную безопасность, что упрощает защиту пользовательских данных и снижает риск случайной или намеренной утечки данных. Дополнительные сведения об этой рабочей нагрузке см. в статье Развертывание инфраструктуры виртуальных рабочих столов (VDI) на Azure Stack хЦи. |
| Высокопроизводительный SQL Server | Azure Stack HCI предоставляет дополнительный уровень устойчивости для высокодоступных критически важных развертываний на основе группы доступности Always On SQL Server. Этот подход также предоставляет дополнительные преимущества, связанные с подходом одного поставщика, включая упрощенную поддержку и оптимизацию производительности, встроенную в базовую платформу. дополнительные сведения об этой рабочей нагрузке см. в разделе Deploy SQL Server on Azure Stack хЦи. |
| Надежная корпоративная виртуализация | Azure Stack HCI соответствует требованиям к виртуализации доверенного предприятия благодаря встроенной поддержке средств обеспечения безопасности на основе виртуализации (VBS). VBS использует Hyper-V для реализации механизма, называемого virtual secure mode, который образует выделенную изолированную область памяти в гостевых виртуальных машинах. С помощью методик программирования можно выполнять определенные, чувствительные к безопасности операции в выделенной области памяти, одновременно блокируя доступ к ней из ОС узла. Это значительно ограничивает потенциальную уязвимость для вредоносных программ, нацеленных на ядро. дополнительные сведения об этой рабочей нагрузке см. в статье развертывание надежных Enterprise виртуализации на Azure Stack хЦи. |
| Служба Azure Kubernetes (AKS) | Вы можете использовать Azure Stack ХЦИ для размещения развертываний на основе контейнера, что повышает эффективность распределения рабочей нагрузки и использования ресурсов. Azure Stack HCI также улучшает гибкость и устойчивость, присущие развертыванию Kubernetes Azure. Azure Stack HCI управляет автоматической отработкой отказа виртуальных машин, обслуживающих узлы кластера Kubernetes, в случае локализованного сбоя базовых компонентов. Это дополняет высокий уровень доступности, встроенный в Kubernetes, который автоматически перезапускает неудачные контейнеры на той же или другой виртуальной машине. Дополнительные сведения об этой рабочей нагрузке см. в статье что такое служба Kubernetes Azure на Azure Stack хЦи?. |
| Горизонтально расширяемое хранилище | дисковые пространства Direct — это базовая технология Azure Stack хЦи, использующая стандартные отраслевые серверы с локально подключенными дисками для обеспечения высокой доступности, производительности и масштабируемости. Использование Локальных дисковых пространств приводит к значительному снижению затрат по сравнению с конкурирующими предложениями на основе сетей хранения данных (SAN) или сетевого хранилища (NAS). Эти преимущества являются следствием инновационного проектирования и широкого спектра усовершенствований, таких как постоянные диски для чтения и записи, контроль четности с зеркальным отображением, вложенная устойчивость и дедупликация. |
| Аварийное восстановление для виртуализированных рабочих нагрузок | Растянутый кластер Azure Stack HCI обеспечивает автоматический переход виртуализированных рабочих нагрузок на дополнительный сайт после сбоя первичного сайта. Синхронная репликация обеспечивает сбой согласованности дисков виртуальных машин. |
| Консолидация центра обработки данных и модернизации | Обновление и консолидация узлов виртуализации старения с помощью Azure Stack ХЦИ может повысить масштабируемость и упростить управление и безопасность среды. Также можно снять с учета устаревшее хранилище SAN, чтобы снизить объем и общую стоимость владения. Администрирование операций и систем упрощается благодаря единым средствам и интерфейсам, а также единой точке поддержки. |
| Запуск служб Azure в локальной среде | Служба «Дуга Azure» позволяет запускать службы Azure где угодно. Это позволяет создавать единообразные гибридные и многооблачные архитектуры приложений с помощью служб Azure, которые могут работать в Azure, в локальной среде, на границе или в других поставщиках облачных услуг. Службы, поддерживающие дугу Azure, позволяют запускать службы данных Azure и службы приложений Azure, такие как служба приложений Azure, функции, Logic Apps, сетка событий и управление API в любом месте для поддержки гибридных рабочих нагрузок. Дополнительные сведения см. в обзоре Azure Arc. |
Преимущества интеграции Azure
Azure Stack ХЦИ позволяет использовать преимущества облачных и локальных ресурсов для совместной работы и мониторинга, обеспечения безопасности и резервного копирования в облако.
После регистрации кластера Azure Stack хЦи в Azure можно изначально использовать портал Azure:
Вы также можете подписываться на дополнительные гибридные службы Azure.
Что необходимо для Azure Stack ХЦИ
Чтобы приступить к работе, вам потребуется следующее.
Убедитесь, что оборудование соответствует требованиям к системе и что сеть соответствует требованиям физической сети и сети узла для Azure Stack хЦи.
Сведения о требованиях к Azure Stack ХЦИ для службы Azure Kubernetes см. в статье требования AKS к Azure Stack хЦи.
Azure Stack ХЦИ оплачивается на уровне ядра на локальных серверах. Текущие цены см. на странице цен на Azure Stack хЦи.
Партнеры по оборудованию и программному обеспечению
Корпорация Майкрософт рекомендует приобрести интегрированные системы, созданные нашими партнерами по оборудованию, и проверили их корпорацией Майкрософт, чтобы обеспечить оптимальную работу Azure Stack ХЦИ. Можно также запустить Azure Stack ХЦИ на проверенных узлах, предлагающих базовый Стандартный блок для кластеров ХЦИ, чтобы предоставить клиентам больше вариантов выбора оборудования. Партнеры корпорации Майкрософт также предлагают единую точку контакта для служб реализации и поддержки.
Некоторые партнеры корпорации Майкрософт разрабатывают программное обеспечение, расширяющее возможности Azure Stack ХЦИ, одновременно позволяя ИТ – администраторам использовать знакомые средства. Дополнительные сведения см. в разделе Служебные приложения для Azure Stack хЦи.
Что такое Azure Stack HCI и как это работает
Привет, Хабр! Сегодня мы хотим рассказать о том, что представляет из себя платформа Azure Stack HCI. В том числе, что это вообще такое, из какого железа собрано, какой софт содержит, как работает, и вот это вот все. Присоединяйтесь!
Это гостевая публикация от ребят из «АльтаСтор». «АльтаСтор» — это системный интегратор, специализирующийся на построении решений для надежного хранения данных. Благодаря накопленной экспертизе в построении кластеров отказоустойчивости и HCI, для каждого клиента подбирается индивидуальное решение, наилучшим образом подходящее для его задач.
Что такое Azure Stack HCI?
Это гиперконвергентное решение, сочетающее в себе несколько продуктов:
С документацией и общими сведениями об Azure Stack HCI можно ознакомиться по ссылке.
Схема стенда
Оборудование
Для построения решения требуется аппаратная платформа, рекомендованная Microsoft. Ведущие производители серверного оборудования — HPE, Dell EMC, Fujitsu, Hitachi, Lenovo и др. — разработали свои конфигурации, протестировали их на совместимость и сертифицировали под Azure Stack HCI.
Полный список совместимого оборудования размещен по адресу.
В зависимости от типов используемых дисков, компоненты платформы будут отличаться.
Мы предпочитаем подобные решения строить на базе серверов Fujitsu с предустановленной операционной системой Windows Server 2019 Datacenter. Данный производитель после продажи поддерживает весь программно-аппаратный комплекс как законченное решение, а не только его аппаратную часть. Это важно и для нас, как для партнеров, и для конечного клиента.
На текущий момент, у Fujitsu сертифицированы пять конфигураций для разных типов дисков, моделей серверов и количества нод. Максимальное количество нод для Azure Stack HCI — 16, минимальное — 2, но некоторые конфигурации ограничивают до 4.
Все совместимые конфигурации Fujitsu можно посмотреть здесь.
Для инсталляции мы выбрали максимально-производительную конфигурацию из сертифицированных на данный момент — Fujitsu Primergy с накопителями SSD для хранения данных, и модулями сверхскоростной памяти Intel Optane, подключенными по интерфейсу NVMe в качестве кэша системы. Мы ожидаем получить программно-определяемый All-Flash массив с показателями, сравнимыми с классическим СХД с SSD дисками и NVMe-кэшем.
Подобные конфигурации по типу носителей есть у All-Flash систем хранения данных лидеров отрасли. Мы знаем, какие показатели по IOPS и задержкам можно на практике получить от подобных систем и рассчитываем на аналогичные показатели у Azure Stack HCI на базе выбранной конфигурации Fujitsu.
Архитектура данного решения Fujitsu подробно описана в документе, доступном по ссылке.
Рекомендуем знакомиться с ним перед инсталляцией.
В документе приведены ограничения архитектуры, типовые схемы подключения, и много другой информации, полезной на этапе внедрения.
Коммутаторы
В решении Fujitsu используются собственные Ethernet-коммутаторы PSWITCH. Для себя мы отметили следующие преимущества:
Подробнее узнать про коммутаторы Fujitsu можно на официальном сайте.
Сервер
Внутри сервера значительную часть места занимают платы памяти Intel Optane.
Intel уделяет много внимания работоспособности в условиях высокой тепловой нагрузки. С одной стороны, для максимально качественного охлаждения используются радиаторы большого размера. С другой, это ограничивает охлаждающий воздушный поток внутри всего сервера.
Это один из ключевых моментов, который учитывается при сертификации конфигурации — необходимо предусмотреть все возможные сценарии, при которых из-за недостаточного охлаждения серверы способны перегреть модуль Optane, или наоборот.
Наши клиенты при переезде серверной комнаты не раз сталкивались с ситуацией, когда система кондиционирования еще не была введена в эксплуатацию. Поэтому мы решили проверить, насколько требовательна данная инсталляция к системе охлаждения и замерить срок работы платформы под нагрузкой вне охлаждаемой серверной.
Тесты проводились при комнатной температуре, но мы не столкнулись ни с тепловыми ограничениями, ни со снижением производительности или появлением ошибок из-за перегрева. На своем опыте убедились, что тестируемые серверы поддерживают заявленную работоспособность при температуре окружающей среды до +45 градусов Цельсия.
Примечание. Этот эксперимент не стоит воспринимать как рекомендацию отказаться от использования специальных серверных помещений с качественной вентиляцией. При выборе поставщика аппаратных решений, обязательно обращайте внимание на максимальный температурный пакет.
Аппаратная платформа в сборе
В тесте использовался только один коммутатор. При коммерческой эксплуатации мы всегда рекомендуем резервировать пути доступа, используя не меньше двух коммутаторов. По нашей статистике, самая частая аппаратная неисправность в кластерах — случайный обрыв кабеля или нарушение контакта в разъеме.
В качестве сервера с управляющим ПО использовался Fujitsu RX1330. На него также были возложены функции арбитра и кворум-сервера.
Развертывание кластера
Первый этап состоял из физического монтажа аппаратных компонентов, подключения интерфейсных кабелей и т.д. Далее следовала настройка ПО, т.к. операционная система уже предустановлена. На каждом сервере развернули Storage Space Direct и построили кластер из 2 нод и арбитра.
Затем мы использовали утилиту Fujitsu Infrastructure Manager — это расширение Windows Admin Center, которое тесно интегрируется с серверным оборудованием Fujitsu и содержит все инструменты управления из Azure, такие как:
Собрали Storage Pool, в нем создали Volumes. В этих томах в дальнейшем расположили виртуальные машины, для которых мы провели тесты производительности. И томами, и виртуальными машинами удобно управлять из одного окна.
Через Fujitsu Infrastructure Manager также удобно делать многие вещи по плановому обслуживанию и апдейту микрокода. Статус всего оборудования наглядно отображается, многое можно автоматизировать.
Существует две версии утилиты Fujitsu Infrastructure Manager — платная и бесплатная:
Чем больше у вас инсталляция, тем ценнее автоматизация, которую дает утилита.
В нашем стенде всего 2 ноды и мы могли делать все работы вручную. Если у вас 4 ноды или больше, то ПО значительно сократит ваши усилия на инсталляцию и администрирование. Стоимость утилиты составляет менее 1% от проекта, но значительно ускоряет ввод оборудования в эксплуатацию.
Для Windows Admin Center оркестратор Fujitsu Infrastructure Manager является пакетом расширения:
На этом же скриншоте виден состав дисковой подсистемы сервера: два модуля Optane используются как расширение кэша, и пять SSD-дисков как пул хранения Tier-1.
Важные моменты
При построении решения есть несколько нюансов, которые нужно обязательно иметь в виду:
Управлять Microsoft Azure Stack HCI можно двумя способами — через Windows Admin Center либо Fujitsu Infrastructure Manager.
Admin Center тоже имеет свои преимущества — развернуть его можно на чем угодно, даже на ноутбуке; есть возможность управления из командной строки. С помощью него администратор может сделать почти все.
Есть еще Cluster Manager — незаменимый инструмент при каких-либо проблемах с кластером.
При развертывании Witness (кворум-сервера) важно добавить его в Active Directory и проверить его доступность всем нодам. Требования к данной задаче минимальны, и она может быть размещена на любом базовом сервере. 
С точки зрения Windows Server, существуют три типа дисковых устройств — NVMe, SSD и HDD. Логика работы следующая: NVMe-устройства — это кэш на чтение/запись, SSD — уровень хранения Tier-1; HDD — уровень хранения Tier-2. Дальше можно настроить политики перемещения данных между пулами. В качестве кэша также могут использоваться модули NVDIMM.
Размер блока для тиринга по умолчанию равен 4К, но может меняться в зависимости от типа файловой системы на виртуальной машине. Это впоследствии будет влиять на производительность.
Мы используем NVMe модули в качестве кэш-памяти, поэтому скорость чтения и записи данных будут сильно отличаться — это будет хорошо видно на тестах производительности:
При добавлении новых нод в существующий кластер, ноды будут автоматически добавлены в Storage pool. Через 15 минут начнется автоматическое перестроение кластера, ребилд и балансировка Storage pool. Это может сказаться на производительности на время перестроения.
Тесты производительности
Теперь перейдем к самому интересному — к нагрузочному тестированию.
Запускаем первый тест с 12 виртуальных машин, работающих на обеих нодах. Профиль нагрузки чтение/запись составляет 70:30, block size = 8k. Размер блока выбрали исходя из того, что большинство современных транзакционных баз данных и OLTP-нагрузок используют именно такой размер блока и примерно аналогичное соотношение чтение/запись.
Устоявшаяся производительность кластера составляет 428k IOPS при задержке 0.487 мс. Это действительно достойный результат, который вполне сопоставим с тем, что можно получить на специализированной all-flash СХД от многих производителей.
Независимые тесты с похожим профилем нагрузки приводятся на ресурсе spcresults.org — это тест SPC-1. Разница с нашей конфигурацией заключается только в размере блока — он составляет 4k.
Если существенно упростить методику сравнения результатов, то можно разделить на два полученные там показатели IOPS для all-flash систем хранения и сравнить с полученными нами цифрами при том же времени отклика. Результаты, полученные на нашем кластере из двух серверов среднего уровня, получаются вполне сравнимыми с большинством СХД.
Безусловно, подобное сравнение не очень корректно, т.к. в нашем случае увеличение количества дисков будет влиять на производительность и задержки совсем иначе, чем у специализированной системы хранения. Но, даже принимая во внимание все указанные допущения, можно сказать, что пару лет назад подобные цифры производительности, можно было увидеть только на многоконтроллерной внешней СХД среднего или даже старшего уровня. Сегодня это достижимо на гиперконвергентном решении.
Картина производительности существенно меняется при включении дедупликации и замеров при прежнем block size = 8k. Если просто включить дедупликацию на том же профиле нагрузки, то производительность станет менее 300k IOPS.
Если запустить два профиля нагрузки с блоком 8КБ где один профиль 100% чтение, а другой 100% запись, то ниже — наилучшие цифры, которые нам удалось получить:
Видим прекрасные результаты по чтению, особенно если учесть задержку в 12 мкс. Optane здесь действительно прекрасно отрабатывает как кэш на чтение при упреждающих алгоритмах по предиктивному переносу данных в кэш. Да и сам пул хранения, расположенный на SSD, тоже демонстрирует очень неплохие цифры на чтение.
А вот скорость записи отличается очень сильно. Здесь накладываются несколько серьезных факторов:
Выводы
Для тех, кто не заинтересован в самостоятельной настройке решения, есть возможность заключить Technical Solution Contract с Fujitsu. В этом случае, технические специалисты вендора развернут все «под ключ» и обеспечат дальнейшую поддержку.
Начало работы с Azure Stack HCI и Windows Admin Center
Область применения: Azure Stack ХЦИ, версии 21H2 и 20H2
Установка Windows Admin Center
центр администрирования Windows — это локально развернутое приложение на основе браузера для управления Azure Stack хЦи. самый простой способ установки Windows центра администрирования — на локальном компьютере управления (настольный режим), хотя его также можно установить на сервере (режиме службы).
для проверки подлинности Azure AD установите Windows центре администрирования на сервере.
при установке центра администрирования Windows на сервере задачи, для которых требуется CredSSP (например, создание кластера и установка обновлений и расширений), должны использовать учетную запись, которая является членом группы администраторов шлюза на сервере центра администрирования Windows. Дополнительные сведения см. в первых двух разделах настройки контроля доступа и разрешений пользователя.
Добавление кластера Azure Stack HCI и подключение к нему
После завершения установки Windows Admin Center вы можете добавить кластер для управления с главной страницы обзора.
Щелкните + Добавить в разделе Все подключения.
Выберите кластер Windows Server для добавления:
Введите имя кластера для управления и нажмите Добавить. Кластер будет добавлен в список подключений на странице обзора.
В разделе Все подключения выберите только что добавленный кластер. Windows Admin Center запустит диспетчер кластеров и откроет панель мониторинга Windows Admin Center для этого кластера.
Мониторинг производительности кластера с помощью панели мониторинга Windows Admin Center
Панель мониторинга Windows Admin Center включает оповещения и сведения о работоспособности серверов, дисков и томов, а также данные об использовании ЦП, памяти и хранилища. В нижней части панели мониторинга отображаются сведения о производительности кластера, такие как количество операций ввода-вывода в секунду и задержка по часам, дням, неделям, месяцам или годам.
Мониторинг производительности отдельных компонентов
В меню Инструменты слева от панели мониторинга вы можете просмотреть подробные сведения о каждом компоненте кластера, а также сводные данные и списки виртуальных машин, серверов, томов и дисков.
Виртуальные машины
Чтобы просмотреть сводные данные о виртуальных машинах, работающих в кластере, выберите Виртуальные машины в меню Инструменты слева.
Чтобы отобразить полный список виртуальных машин, работающих в кластере, в том числе сведения об их состоянии, серверах узлов, использовании ЦП, нагрузке на память, потребности в памяти, назначенной памяти и времени доступности, щелкните Список вверху страницы.
Серверы
Чтобы просмотреть сводные данные о серверах в кластере, выберите Серверы в меню Инструменты слева.
Чтобы отобразить полный список серверов в сервере, в том числе сведения об их состоянии, времени доступности, производителе, модели и серийном номере, щелкните Список вверху страницы.
Чтобы просмотреть сводные данные о томах в кластере, выберите Тома в меню Инструменты слева.
Чтобы отобразить полный список томов в кластере, в том числе сведения об их состоянии, файловой системе, устойчивости, размере, использовании хранилища и количестве операций ввода-вывода в секунду, щелкните Список вверху страницы.
Диски
Чтобы просмотреть сводные данные о дисках в кластере, выберите Диски в меню Инструменты слева.
Чтобы отобразить полный список дисков в кластере, в том числе сведения об их серийном номере, состоянии, модели, размере, типе, использовании, расположении, сервере и емкости, щелкните Список вверху страницы.
Виртуальные коммутаторы
Чтобы просмотреть параметры виртуального коммутатора в кластере, щелкните Виртуальные коммутаторы в меню Инструменты слева, а затем выберите имя виртуального коммутатора, для которого нужно отобразить параметры. Windows Admin Center отобразит сетевые адаптеры, связанные с виртуальным коммутатором, включая их IP-адреса, состояние подключения, скорость соединения и MAC-адрес.
Добавление счетчиков с помощью Монитора производительности
Используйте Монитор производительности, чтобы просматривать и сравнивать счетчики производительности для ОС Windows, приложений или устройств в реальном времени.
Сбор диагностических сведений
Выберите Диагностика в меню Инструменты, чтобы получить сведения для устранения неполадок в кластере. Если вы обратитесь в службу поддержки Майкрософт, ее специалисты могут запросить такие данные.
Дальнейшие действия
Чтобы отслеживать журнал производительности на кластерах Azure Stack ХЦИ, см. также: