Чуть менее месяца назад — 29 января 2016 года, компания Microsoft выпустила первую публичную раннюю версию продукта под названием Azure Stack. Сегодня я расскажу о том, что это такое и почему этот продукт важен для облачной стратегии компании Microsoft.
Первый анонс Azure Stack был сделан на конференции Microsoft Ignite в Чикаго 4 мая 2015 года. Тогда этот анонс вызвал большой резонанс в СМИ и среди пользователей Microsoft Azure. Еще бы — многие потрясающие технологии, на которых работает Microsoft Azure, станут доступны всем желающим для развёртывания в своём собственном ЦОДе. Много лет крупные заказчики и сервис-провайдеры, операторы собственных ЦОДов, просили нас — дайте нам кусочек Azure, нам нравится технология, и мы хотим использовать её в своих ЦОДах. И вот, уже совсем скоро, данное желание станет реализуемым.
Azure Stack — это действительно «Azure in your datacenter». В отличие от Windows Azure Pack, который был похож на Azure снаружи, но был очень непохож внутри, тут общих черт значительно больше. Azure Stack использует ту же модель Azure Resource Manager (ARM), что и новый портал Azure. Общая часть кода между Azure Stack и Azure в разы больше, чем у Windows Azure Pack. Это значит, что сервис, разрабатываемый под модель ARM, можно будет развернуть как в Microsoft Azure, так и в Azure Stack — хоть у себя в серверной, хоть у сервис-провайдера в соседнем городе.
Используя одну и ту же модель ARM и одни и те же средства разработки, вы можете создавать универсальные сервисы по облачной модели Microsoft, а потом разворачивать их там, где вам требуется — у себя, у сервис-провайдера, или в Microsoft Azure. Виртуальные машины, развёрнутые в Azure, можно будет безболезненно перенести в ЦОД местного сервис-провайдера, использующего Azure Stack, и наоборот.
Нужно понимать, что Azure Stack Technical Preview 1 — это еще очень ранняя версия, которая абсолютно не подходит для развёртывания в продуктивной среде. Вы можете достаточно быстро развернуть решение на базе одного физического сервера на базе Windows Server 2016 Technical Preview 4 (про это на Хабре уже писали) и начать изучать возможности решения. Если вы уже разрабатывали под ARM и размещали решение в Microsoft Azure, вы можете проверить, будет ли это решение работать на Azure Stack.
Многие функиональные элементы в Azure Stack Technical Preview 1 пока не доступны, так что судить о финальной версии продукта пока рано. Более того, к моменту релиза Azure Stack, могут поменяться и компоненты внутри Microsoft Azure, поэтому и Azure Stack будет менятся вслед за ними, чтобы оставаться «Azure consistent».
Прежде всего отмечу одно большое отличие Azure Stack от Windows Azure Pack. Здесь нет отдельных порталов для администратора сервиса и для потребителя сервиса. Здесь есть только один портал, и если пользователь является владельцем подписки «Default Provider Subscription» — то он является администратором сервиса и может делать всё.
По умолчанию пользователь, который был введёт при развёртывании Azure Stack TP1 является администратором сервиса. Чтобы добавить новых администраторов сервиса, нужно зайти в Subscriptions и добавить новые учётные записи из Azure AD с правами Owner в подписку «Default Provider Subscription».
В Azure Stack используется концепция ресурсных провайдеров («Resource Providers»), через которые осуществляется взаимодействие различных компонентов. Часть ресурсных провайдеров используется для предоставления сервисов конечным потребителям, а часть — внутренняя, её потребители не видят.
Все ресурсные провайдеры размещаются в локациях («Locations»). Это логическая сущность, предназначенная для разделения сервисов по различным сайтам (ЦОД в Москве, ЦОД в Санкт-Петербурге и т.п.). По умолчанию в TP1 автоматически создаётся локация «local» и все ресурсные провайдеры добавляются туда.
После установки Azure Stack TP1 доступно 4 ресурсных провайдера, на базе которых можно оказывать сервисы потребителям:
1) Compute Provider — провайдер для предоставления виртуальных машин на базе Hyper-V 2016
2) Storage Provider — провайдер для предоставления служб хранилища. В TP1 доступны Blob Storage (как Page blob для дисков ВМ, так и Block blob для данных) и Table Storage. В будущем добавятся Queue Storage и File Storage. Кнопки под них в интерфейсе уже есть, но сами сервисы пока не работают.
3) Network Provider — провайдер для предоставления сетевых служб. Виртуальные сети, сетевые балансировщики, внешние IP и т.п.
4) Subscriptions — провайдер, позволяющий потребителям создавать свои собственные тарифные планы и подписки. Функционал, предназначенных в первую очередь для реселлеров услуг сервис-провайдеров по модели «White label».
На GitHub так же доступны для скачивания дополнительные ресурсные провайдеры PaaS, устанавливаемые дополнительно:
1) SQL Server — провайдер для предоставления баз данных SQL Server
2) MySQL — провайдер для предоставления баз данных MySQL
3) Web Apps — первая часть переноса Azure App Service на Azure Stack, пока только в виде Web Apps.
В будущем планируется появление большого количества ресурсных провайдеров как от Microsoft (которые позволят переносить технологии из Microsoft Azure в Azure Stack), так и от сторонних фирм (которые добавят в портал Azure Stack уникальный функционал, не доступный в Microsoft Azure).
Администратор портала Azure Stack готовит сервисные предложения («Offers»), в которые может включаться один или несколько тарифных планов («Plans»). В рамках тарифного плана выбираются доступные сервисы и локации, из которых потребитель может заказать эти сервисы, а также задаются квоты на ресурсы.
Потребители сервиса добавляют себе подписки на предложения («Subscriptions»). Если предложение публичное (Public), то потребитель может подписаться на него самостоятельно. Если же предложение не публичное (Private), то на него потребителя может подписать администратор сервиса вручную. Схожая идеология планов и подписок используется и в Windows Azure Pack.
Пользователь, зайдя на портал Azure Stack впервые, и авторизовавшись с помощью учётной записи в Azure AD, должен добавить себе подписку. Для этого он нажимает на «Get a Subscription» и выбирает доступный публичный оффер.
Функционал ценообразования и биллинга пока не реализован в Technical Preview 1, так что сообщение «Unable to display pricing» — это нормально.
После добавления подписки, пользователь может нажать на кнопку "+ New" и увидит все доступные ему сервисы. По умолчанию из коробки этот список весьма скудный: Template Deployment (развёртывание ARM-сервиса из шаблона по JSON-описанию), Resource Group, Storage Account и виртуальная машина Windows Server 2012 R2. После добавления своих шаблонов (в том числе и Linux-шаблоны, уже появилась инструкция для CentOS) и PaaS-провайдеров, упомянутых выше, набор сервисов выглядит будет выглядеть уже интереснее.
Интерфейс создания новой виртуальной машины абсолютно такой же, как и на новом портале Azure.
Во время создания ВМ можем наблюдать, на каком этапе находится процесс.
После создания мы можем видеть те же самые действия и свойства, что и на новом портале Microsoft Azure. Напоминаю, что данные по потреблению ресурсов пока недоступны, поэтому мы видим «No available data» вместо графиков, это нормально.
Подключение к ВМ производится через RDP для Windows и SSH для Linux. Консольного доступа (как в Windows Azure Pack) тут нет, точно так же как и в Microsoft Azure.
В свойстах Storage Account мы можем видеть Blob, Table, Queue и File services.
В TP1 работают только блобы и таблицы. Очереди и файлы — в следующих версиях.
На этом пока всё. Если вас заинтересовал Microsoft Azure Stack — скачивайте Technical Preview 1, устанавливайте и тестируйте. Если возникнут вопросы — заходите в Azure Stack Wiki, там очень много полезных материалов.
Первый анонс Azure Stack был сделан на конференции Microsoft Ignite в Чикаго 4 мая 2015 года. Тогда этот анонс вызвал большой резонанс в СМИ и среди пользователей Microsoft Azure. Еще бы — многие потрясающие технологии, на которых работает Microsoft Azure, станут доступны всем желающим для развёртывания в своём собственном ЦОДе. Много лет крупные заказчики и сервис-провайдеры, операторы собственных ЦОДов, просили нас — дайте нам кусочек Azure, нам нравится технология, и мы хотим использовать её в своих ЦОДах. И вот, уже совсем скоро, данное желание станет реализуемым.
Azure Stack — это действительно «Azure in your datacenter». В отличие от Windows Azure Pack, который был похож на Azure снаружи, но был очень непохож внутри, тут общих черт значительно больше. Azure Stack использует ту же модель Azure Resource Manager (ARM), что и новый портал Azure. Общая часть кода между Azure Stack и Azure в разы больше, чем у Windows Azure Pack. Это значит, что сервис, разрабатываемый под модель ARM, можно будет развернуть как в Microsoft Azure, так и в Azure Stack — хоть у себя в серверной, хоть у сервис-провайдера в соседнем городе.
Используя одну и ту же модель ARM и одни и те же средства разработки, вы можете создавать универсальные сервисы по облачной модели Microsoft, а потом разворачивать их там, где вам требуется — у себя, у сервис-провайдера, или в Microsoft Azure. Виртуальные машины, развёрнутые в Azure, можно будет безболезненно перенести в ЦОД местного сервис-провайдера, использующего Azure Stack, и наоборот.
Нужно понимать, что Azure Stack Technical Preview 1 — это еще очень ранняя версия, которая абсолютно не подходит для развёртывания в продуктивной среде. Вы можете достаточно быстро развернуть решение на базе одного физического сервера на базе Windows Server 2016 Technical Preview 4 (про это на Хабре уже писали) и начать изучать возможности решения. Если вы уже разрабатывали под ARM и размещали решение в Microsoft Azure, вы можете проверить, будет ли это решение работать на Azure Stack.
Многие функиональные элементы в Azure Stack Technical Preview 1 пока не доступны, так что судить о финальной версии продукта пока рано. Более того, к моменту релиза Azure Stack, могут поменяться и компоненты внутри Microsoft Azure, поэтому и Azure Stack будет менятся вслед за ними, чтобы оставаться «Azure consistent».
Работа с Azure Stack Technical Preview 1
Прежде всего отмечу одно большое отличие Azure Stack от Windows Azure Pack. Здесь нет отдельных порталов для администратора сервиса и для потребителя сервиса. Здесь есть только один портал, и если пользователь является владельцем подписки «Default Provider Subscription» — то он является администратором сервиса и может делать всё.
По умолчанию пользователь, который был введёт при развёртывании Azure Stack TP1 является администратором сервиса. Чтобы добавить новых администраторов сервиса, нужно зайти в Subscriptions и добавить новые учётные записи из Azure AD с правами Owner в подписку «Default Provider Subscription».
В Azure Stack используется концепция ресурсных провайдеров («Resource Providers»), через которые осуществляется взаимодействие различных компонентов. Часть ресурсных провайдеров используется для предоставления сервисов конечным потребителям, а часть — внутренняя, её потребители не видят.
Все ресурсные провайдеры размещаются в локациях («Locations»). Это логическая сущность, предназначенная для разделения сервисов по различным сайтам (ЦОД в Москве, ЦОД в Санкт-Петербурге и т.п.). По умолчанию в TP1 автоматически создаётся локация «local» и все ресурсные провайдеры добавляются туда.
После установки Azure Stack TP1 доступно 4 ресурсных провайдера, на базе которых можно оказывать сервисы потребителям:
1) Compute Provider — провайдер для предоставления виртуальных машин на базе Hyper-V 2016
2) Storage Provider — провайдер для предоставления служб хранилища. В TP1 доступны Blob Storage (как Page blob для дисков ВМ, так и Block blob для данных) и Table Storage. В будущем добавятся Queue Storage и File Storage. Кнопки под них в интерфейсе уже есть, но сами сервисы пока не работают.
3) Network Provider — провайдер для предоставления сетевых служб. Виртуальные сети, сетевые балансировщики, внешние IP и т.п.
4) Subscriptions — провайдер, позволяющий потребителям создавать свои собственные тарифные планы и подписки. Функционал, предназначенных в первую очередь для реселлеров услуг сервис-провайдеров по модели «White label».
На GitHub так же доступны для скачивания дополнительные ресурсные провайдеры PaaS, устанавливаемые дополнительно:
1) SQL Server — провайдер для предоставления баз данных SQL Server
2) MySQL — провайдер для предоставления баз данных MySQL
3) Web Apps — первая часть переноса Azure App Service на Azure Stack, пока только в виде Web Apps.
В будущем планируется появление большого количества ресурсных провайдеров как от Microsoft (которые позволят переносить технологии из Microsoft Azure в Azure Stack), так и от сторонних фирм (которые добавят в портал Azure Stack уникальный функционал, не доступный в Microsoft Azure).
Администратор портала Azure Stack готовит сервисные предложения («Offers»), в которые может включаться один или несколько тарифных планов («Plans»). В рамках тарифного плана выбираются доступные сервисы и локации, из которых потребитель может заказать эти сервисы, а также задаются квоты на ресурсы.
Потребители сервиса добавляют себе подписки на предложения («Subscriptions»). Если предложение публичное (Public), то потребитель может подписаться на него самостоятельно. Если же предложение не публичное (Private), то на него потребителя может подписать администратор сервиса вручную. Схожая идеология планов и подписок используется и в Windows Azure Pack.
Пользователь, зайдя на портал Azure Stack впервые, и авторизовавшись с помощью учётной записи в Azure AD, должен добавить себе подписку. Для этого он нажимает на «Get a Subscription» и выбирает доступный публичный оффер.
Функционал ценообразования и биллинга пока не реализован в Technical Preview 1, так что сообщение «Unable to display pricing» — это нормально.
После добавления подписки, пользователь может нажать на кнопку "+ New" и увидит все доступные ему сервисы. По умолчанию из коробки этот список весьма скудный: Template Deployment (развёртывание ARM-сервиса из шаблона по JSON-описанию), Resource Group, Storage Account и виртуальная машина Windows Server 2012 R2. После добавления своих шаблонов (в том числе и Linux-шаблоны, уже появилась инструкция для CentOS) и PaaS-провайдеров, упомянутых выше, набор сервисов выглядит будет выглядеть уже интереснее.
Интерфейс создания новой виртуальной машины абсолютно такой же, как и на новом портале Azure.
Во время создания ВМ можем наблюдать, на каком этапе находится процесс.
После создания мы можем видеть те же самые действия и свойства, что и на новом портале Microsoft Azure. Напоминаю, что данные по потреблению ресурсов пока недоступны, поэтому мы видим «No available data» вместо графиков, это нормально.
Подключение к ВМ производится через RDP для Windows и SSH для Linux. Консольного доступа (как в Windows Azure Pack) тут нет, точно так же как и в Microsoft Azure.
В свойстах Storage Account мы можем видеть Blob, Table, Queue и File services.
В TP1 работают только блобы и таблицы. Очереди и файлы — в следующих версиях.
На этом пока всё. Если вас заинтересовал Microsoft Azure Stack — скачивайте Technical Preview 1, устанавливайте и тестируйте. Если возникнут вопросы — заходите в Azure Stack Wiki, там очень много полезных материалов.
Комментарии (10)
Aivendil
24.02.2016 17:52В том и задумка, что две простые виртуалки зачастую получаются дешевле одной навороченной. Т.е. если в прайсинге будет возможность создать виртуалу для которой провайдер гарантирует HA, то она будет банально дороже.
Neuronix
24.02.2016 18:18Ок, представим сценарий. У меня виртуалка с 32 ядрами, кучей ОЗУ, супер быстрыми дисками и т.д. и т.п. В итоге для того, чтобы получить не падающий по вине провайдера услуги, я, по логике MS, должен купить еще одну такую же машину и держать её постоянно включенной. Ок, по идее, можно размазать приложение по двум серверам, НО это сразу же усложнение ПО, да и многое уже готовое ПО просто нереально переписать под эту задачу (нет сорцов, дорого, etc). Вот ну никак меня не убедите, что падающая без предупреждения виртуалка — это нормальный сценарий. Это просто бред. По крайней мере нужно предлагать возможность включения live migration, пусть это и будет дороже (но это будет явно не дороже еще одной высокопроизводительной VM).
Программа BizSpark для стартапов предлагает вроде как ознакомиться с преимуществами облака от MS, но у меня лично после ознакомления есть стойкое желание держаться как можно подальше от него. На поиграться сойдет, критичные процессы — нет, спасибо.Aivendil
24.02.2016 18:34Вы совершенно верно поняли идею:
можно размазать приложение по двум серверам
. Понятно, что дл якого-то это минус, но такова концепция облаков. Новые приложения, почти все изначально проектируются под эти механизмы.
но это будет явно не дороже еще одной высокопроизводительной VM
В том и дело, что предлагается создать две менее производительные VM. А еще лучше десяток, совсем простых. И автоматизировать их развёртывание. И добавить правило, которое будет автоматически добавлять/удалять эти VM-ки по мере увеличения/уменьшения нагрузки на приложение. Я думаю, логика понятна.
Я не спорю, что для ваших конкретных потребностей это может оказаться неудобно. Однако таковы реалии. Я кстати согласен, что мне бы хотелосьвозможность включения live migration
за отдельную плату. Но у MS явно другие планы — вот что они сами говорят о HA.
Neuronix
Общие впечатления от использования Azure — громоздко и неудобно. Интерфейс сделан такое ощущение, что для роботов. Обычный юзер там разберется после бутылки, а то и не одной… Отсутствие консольного доступа к юниксовым машинами это вообще за гранью (однажды отсушил себе доступ по SSH и всё, привет). Непонятная логика расчета потребления денег — все эти "приблизительно", как-то не внушают доверия. Однажды утром увидел что машина, которая должна дойти до конца расчетного месяца с плюсом на счету просто кончилась за ночь. Уведомления о таких случаях по дефолту тоже, кстати, нет — нужно продираться сквозь дикие дебри личного кабинета, чтобы настроить простейшие оповещения.
Извините за эту экспрессию, но наболело...
ALTF13
Как вы приобретаете Azure? Напрямую через сайт, оплачивая банковской картой? Или через локального реселлера?
Neuronix
Я пользуюсь предложением для стартапов BizSpark. Кстати вот еще вспомил одну веселуху — перезагрузка виртуальных машин (полагаю, что скорее всего перезагружается хост) без предупреждения (!!!). Искал информацию по этому вопросу — MS говорит, мол это не баг это фича. Настраивайте HA. Это как вообще?
Aivendil
Это действительно "фича" облака. Облако это не совсем тоже самое, что и виртуальная инфраструктура в прежнем понимании, точнее совсем не тоже самое.
Тут предлагается использовать простоту горизонтального масштабирования вместо увеличения ресурсов одной машины. Т.е. если вам нужен стабильно работающий сервис, то вместо того, чтобы делать одну виртуалку отказоустойчивой, предлагается сделать две (можно больше, по вкусу), но попроще и объединить их в HA домен (в случае Azure — availability set). Тогда облако будет знать, что эти машинки должны находиться на разных хостах, чтобы сервис оставался доступным, независимо от того, что происходит с хостом.
Эта фича вообще характерна для всех облаков. Вместо отказоустойчивости на уровне инфрастурктуры, предлагается сделать упор на отказоустойчивость уровня приложения. Отсюда и такое количество встроенных инструментов балансировки и т.д.
Neuronix
Это сразу же увеличение цены на х2 и может быть неприемлемо для конечных пользователей. По-моему проще о даунтайме уведомить заранее, а не впаривать НА. В конце концов на дворе 2016 год и есть всякие live migration… Может быть НА и правильно, но вызывает волны ненависти со стороны кошелька.
SychevIgor
о availability set — написано много документации, особенно в sla https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_0/ — но ни кто их лет 5 не читает(это не к претензия к вам, просто документацию читают уже после фейла).
О плановой перезагрузке- уведомления приходят по меньшей мере год. В письме указывается регионы и даты. В этом году будет еще одно улучшение.
SychevIgor
Самая забавное, что в статье говорится про private cloud, в котором нет биллинга родного, а ругают большой Public Azure.
Согласен, что ценообразование сложное(compute minutes + storage space+ storage transactions + network bandwidth — где последние 2 параметра можно лишь приблизительно)- но альтернатива — в большую сторону округлить.
Думаю основная претензия по слову приблизительная, базируется на надписи при выборе виртуальной машины, что цена приблизительная. Там если почитать, то написано из расчета что машина работает 744ч в месяц(24*31). Но 31 день -не каждый месяц, да и машины люди выключают на ночь и выходные часто- чтобы экономить. Как это с fix price совместить- это отдельный разговор.
по поводу слишком быстрого слива денег за 1 ночь, что у вас там было то?
По доступу к консоли уже работы ведутся. https://feedback.azure.com/forums/216843-virtual-machines/suggestions/3761826-virtual-machine-console-access
Sash доступ можно и без этого восстановить правда.