Welcome to Azure. Кто - кто в теремочке живет?
Медведь и полез в теремок. Лез-лез, лез-лез – никак не может влезть и говорит:
– А я лучше у вас на крыше жить буду.
– Да ты нас раздавишь!
– Не-е, не раздавлю.
– Ну, тогда полезай!
Полез медведь на крышу и только уселся – трах-тарарах! – затрещал теремок и весь развалился. Еле-еле успели из него выскочить мышка-норушка, лягушка-квакушка, зайчик-побегайчик, лисичка-сестричка, волчок-серый бочок – все целы и невредимы.
Собсвтенно я, надеюсь, понимание уровня «блондинки» для чего существует клауд и как оно все крутится появилось, потому давайте как копнем глубже как вся эта кухня работает.
Достаточно инетересно почитать как все-таки Микрософт докатился до жизни такой – создание своего облачного сервиса. Казалось бы – продавали всем бы Форточки, до офисы, и не тужили бы:) Микрософт увидели, что их заказчики требуют все более гибкие решения, не только для ихо корпоративного сектора, но и для собственных решений. Ещё одним фактором стало – «озеленение» IT:) Для нашей страны – это не столь актуально, хотя для более развитых стран – это очень важно. Суть простая – чем больше Ваша компания употребляет электричества – тем больше она платит налоги. Все потому, что чем больше Ваша компания тратить энергии – тем больше ее надо выработать, а это в свою очередь приводит к тому, что в атмосферу выкидывает все больше ядовитых веществ. Потому, чтобы запустить свои решения, клиентам Микрософта, приходилось покупать датацентры, нанимать администраторов, обустраивать инфраструктуру, вообщем всячески ухаживать за железками. Микрософт увидели, что надо, и что это очень поможет людям ( да и че греха таить – поможет бабла отгрести:) ) – вышли с Ажуром. Пока у них получается:) При том что качество сервиса все более растет. Итак, из чего состоят «облака»?…
Вначале про «железяки»
Все элементарно – датацентр – это огромное количество компьютеров – стоят, гудят, летом возле них жарко, зимой тоже. Процесс постройки датацентров прошел длительную эволюцию к тому , чем является сейчас. Первая генерация серверов – это самые распростарненные датацентры – много компьютеров, куча упсов, рэки, и везде жара:) Собственно главное в первой генерации датацентров – это построить такой центр, потому как никто не считал сколько тратиться на суппорт такого центра.
Вторая генерация датацентров – это датацентры в которых начали считать деньги:) Собственно, расчет того сколько стоит каждый день работы датацентра первой генерации привел к тому, что начался поиск более дешевых решений – в основном направленный на экономию электроенергии – например у датацентров начали появлятся гидроэлектростанции.
Третья генерация – это то,чем дышит теперешний Микрософт. Теперешний датацентр – это контейнер:) Знаете, такие контейнеры в которых перевозят что-то на кораблях? Вот именно в таких (почти) контейнерах живут серваки Микрософта. В одном таком контейнере можна разместить от 1800 до 2500 компьютеров. Каждый контейнер имеет вход для электричества, охлаждения, и сети. К тому же, он защищен от воздействия окружающей среды, потому может стоять хоть на улице ( кстати, многие датацентры находятся под октрытым небом! ). Очень удобно – приехала фура, выгрузила контейнер – подключили питание, охлаждение и сеть – и вот у вас на 2500 компов больше:)
Вообщем выглядит круто – куча железок, можна поставить ещё кучу и все будет работать:)
Как же оно там все работает?
Окей, давайте представим, о чем мы думаем когда пишем обычну аппликацию – о том чтобы написать! Нас не волнует в данный момент сколько там памяти осталось, как грузится процессор, не перегревается ли чего-нить. Обо всем этом за нас думает компьютер!
Теперь давайте подымемся на более верхний уровень – Мы пишем приложение для большой корпорации, которое будет использованно огромным количеством людей, отделов, компаний. Все это должно храниться в одном месте, данные должны сохраняться, а также все это должно легко расширятся. Вот тут-то и появляются новые загадки и головная боль! Мы должны думать о куче вещей, типа лоад балансера, ДНС, прт этом Вы должны контроллировать разрешения для разных типов пользователей. Вообщем, чем больше система – тем больше Вам надо думать как оно все будет взаимодействовать.
Windows Azure – делает очень много вещей для Нас:) Вы не будете тратить столько времени на инфраструктуру, как тратили когда управляли своим датацентром. Теперь, когда Вы пишете, аппликацию для крупной компании , и при этом хостите ее в Облаках – Ажур сам решит вопросы связанные с сетью, с восстановлением в случае поломки аппаратуры, и т.д, и т.п. Тоесть Вы сможете полностью сконцентрироваться на написании аппликации, а не на настройке оборудования.
Фабрика
Помните, я писал про Бога всех машин в Ажуре?:) Именно фабрика им и является! Давайте сразу разделим два понятия – фабрика и контроллер фабрики. В двух словах – фабрика – это операционная система, в тоже время контроллер фабрики – это ядро этой системы:).
Фабрика знает про все машины которые есть в Ажуре. Фабричный Контроллер – это просто приложение, которое копируется на все компьютеры которые есть под управление фабрики. Каждая нода фабрики знает про состояние любой другой ноды фабрики, потому если одна из нод сгорела, вся инфа про ее состояние хранится на одной из выживших нод. Со всем этим счастья контроллер фабрики работает через драйвера.
Как видим, без контроллера фабрики, в Ажуре вообще мало чего происходит, но также, контроллер занимается тем, что распределяет ресурсы. Он анализирует модель вашего сервиса, сколько и где ресурсов осталось, и на основании этих данных размещает Ваше приложение на том или ином сервере.
Кстати, сущностями Ваших сервисов управляет также он. Каждый раз когда мы размещаем Веб роль на ажуре, для каждой веб роли поднимается отдельная виртуальнам машина. Если Ваше приложение вдруг зависло, то контроллер попытается восстановить работу Вашего приложения. По моим наблюдениям – он просто рестартует машину.Перед тем, как захостить Ваше приложение на ВМ, контроллер пропускает ее через ряд тестов, чтобы определить, что виртуальная машина работает хорошо, и что оборудование работает достойно вашего приложения:) Согласитесь, неприятно если Ваше приложение обвалится после 10 минут работы из-за сгоревшегно оборудования.
Модель сервиса (Service Model)
Помните в прошлом посте, мы задавали два конфигурационных файла? Вооооот. Мы задавали модель сервиса. Тут мы определяем:
- Конфигурацию того, что есть Наш сервис.
- Как сервисы коммуницируют друг-с-другом.
- Сколько экземпляров Ваших сервисов будут крутиться в Ажуре.
Дак *.cscfg очень похож на web.config.
Спасибо, кэп, где-то так и есть:) И даже больше, мы можем хранить там свои настроки.
Для этого нужно вначале открыть файл с расширение *.csdef и определить там наш аттртбут:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="WindowsAzureProject1"
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WebRole name="TestApplication1">
<Sites>
<Site name="Web">
<Bindings>
<Binding name="Endpoint1" endpointName="Endpoint1" />
</Bindings>
</Site>
</Sites>
<Endpoints>
<InputEndpoint name="Endpoint1" protocol="http" port="80" />
</Endpoints>
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
<ConfigurationSettings>
<Setting name="MyCustomSettingInAzure"/>
</ConfigurationSettings>
</WebRole>
</ServiceDefinition>
Как видим я добавил секцию под название ConfigurationSettings с настройкой под названием MyCustomSettingInAzure. Теперь давайте откроем файл с разширением *.cscfg и добавим туда значение нашего параметра:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="WindowsAzureProject1"
xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"
osFamily="1" osVersion="*">
<Role name="TestApplication1">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"
value="UseDevelopmentStorage=true" />
<Setting name="MyCustomSettingInAzure" value="ыыы"/>
</ConfigurationSettings>
</Role>
</ServiceConfiguration>
Как видим значение нашего параметра «ыыы», что сразу показывает Наш интеллект:)
Для того, чтобы считать этот параметр в коде надо написать такую строчку: view source
var trollsSays = RoleEnvironment.GetConfigurationSettingValue("MyCustomSettingInAzure");
Также в конфигурационном файле Вы можете указать какую конфигурацию виртуальной машины должно использовать ваше приложение. Для того чтобы задать этот параметр – стоит зайти в настройки вашей веб роли. Внимательно продумывайте этот шаг – потому как чем круче виртуальную машину Вы выберите – тем дороже она вам обойдется. Не стоит на блог брать машину с 16 гигами оперативки, и 4 ядарми.
Ниже преведнны типы машин , и цены за их использование:
| Compute Instance Size | CPU | Memory | Instance Storage | I/O Performance | Cost per hour |
| Extra Small | 1.0 GHz | 768 MB | 20 GB | Low | $0.05 |
| Small | 1.6 GHz | 1.75 GB | 225 GB | Moderate | $0.12 |
| Medium | 2 x 1.6 GHz | 3.5 GB | 490 GB | High | $0.24 |
| Large | 4 x 1.6 GHz | 7 GB | 1,000 GB | High | $0.48 |
| Extra large | 8 x 1.6 GHz | 14 GB | 2,040 GB | High | $0.96 |
Как видите, самая дорогая тачка стоит практически 1 доллар в час – приблизительно 720 долларов в месяц – дороговатое удовольствие для блога, не находите?
Апгрейды
Тада, в любом случае вам прийдется апдейтить Ваш кода, каким бы классным он небыл. В течении разработки приложения под Ажур Вы увидите что есть два типа апгрейдов – статический и накатка. Вопрос апгрейда кода стоит достаточно жестко, потому как если Ваша аппликация используеюся очень активно – статический апгрейд на некоторе время выключит виртуалку из сети, и пользователи будут недовольны, в тоже время апгрейд понакатке проапгрейдить вашу аппликацию не выключая ее ни на секунду.
В любом случай апгрейд должен проходить вначале на staging машине, для того чтобы проверить как работает новая версия аппликации, и только потом перемещенна на продакшен.
Что такое статический апдейт? (Static Upgrade)
По сути – статический апдейт это когда Вы меняете ВСЕ! Допустим в случае когда у Вас поменялась архитектура аппликации, или добавились какие-то компоненты. В таком случае очень любят использовать VIP замену. VIP – это Virtual IP, а не то что Вы подумали:) По сути, это тот момент когда Ваш staging среда меняется айпишками с продакшен машиной. А на ней вы уже делаете загрузку новой версии Вашего сервиса. Потом замена айпишками происходит опять.
Что такое апдейт по накатке? (Rolling Upgrade)
Это такой апдейт, в течении которого Вы заменяете не всю аппликацию, а только часть. Помните, в течении такого апдейта нельзя поменять сервисную модель вашей аппликации.
Как вся эта радость проходит?
Представте что у Вас есть 10 машин, на которых крутиться Ваша веб аппликация. Вы хотите проапдейтить аппликацию, потому как некоторые странички потерпели изменения. В процессе апдейта по-накатке, фабричный контроллер отключает айпи адрес ноды из своего лоад балансера, тоесть он уже не будет перенаправлять запросы от клиента на эту машину, после чего останавилвает эту машину. После остановки машины, заливает на нее новый код, и опять запускает. Как только машина запустилась, фабричный контроллер подключает айпи адрес а лоад балансеру, и переходит к другой машине. Логично, что такой апдейт возможен только в случае более одной веб роли:)
В следующих своих постах я постараюсь покрыть больше железячную часть Azure. Дальше будет.
Полезные ссылки:
Компании из статьи
| Microsoft Украина |  Украинское подразделение компании Microsoft. |