1 березня 2011 р.

Welcome to Azure. Кто - кто в теремочке живет?

Медведь и полез в теремок. Лез-лез, лез-лез – никак не может влезть и говорит:

– А я лучше у вас на крыше жить буду.

– Да ты нас раздавишь!

– Не-е, не раздавлю.

– Ну, тогда полезай!

Полез медведь на крышу и только уселся – трах-тарарах! – затрещал теремок и весь развалился. Еле-еле успели из него выскочить мышка-норушка, лягушка-квакушка, зайчик-побегайчик, лисичка-сестричка, волчок-серый бочок – все целы и невредимы.


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

Достаточно инетерсно почитать как все-таки Микрософт докатился до жизни такой - создание своего облачного сервиса. Казалось бы - продавали всем бы Форточки, до офисы, и не тужили бы:) Микрософт увидели, что ихние заказчики требуют все более гибкие решения, не только для ихнего корпоративного сектора, но и для собственных решений. Ещё одним фактором стало - "озеленение" IT:) Для нашей страны - это не столь актуально, хотя для более развитых стран - это очень важно. Суть простая - чем больше Ваша компания употребляет электричества - тем больше она платит налоги. Все потому, что чем больше Ваша компания тратить энергии - тем больше ее надо выработать, а это в свою очередь приводит к тому, что в атмосферу выкидывает все больше ядовитых веществ. Потому, чтобы запустить свои решения, клиентам Микрософта, приходилось покупать датацентры, нанимать администраторов, обустраивать инфраструктуру, вообщем всячески ухаживать за железками. Микрософт увидели, что надо, и что это очень поможет людям ( да и че греха таить - поможет бабла отгрести:) ) - вышли с Ажуром. Пока у них получается:) При том что качество сервиса все более растет. Итак, из чего состоят "облака"?...

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

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

Третья генерацтя - это то,чем дышит теперешний Микрософт. Теперешний датацентр - это контейнер:) Знаете, такие контейнеры в которых перевозят что-то на кораблях? Вот именно в таких (почти) контейнерах живут серваки Микрософта. В одном таком контейнере можна разместить от 1800 до 2500 компьютеров. Каждый контейнер имеет вход для электричества, охлаждения, и сети. К тому же, он защищен от воздействия окружающей среды, потому может стоять хоть на улице ( кстати, многие датацентры находятся под октрытым небом! ). Очень удобно - приехала фура, выгрузила контейнер - подключили питание, охлаждение и сеть - и вот у вас на 2500 компов больше:)

Вообщем выглядит круто - куча железок, можна поставить ещё кучу и все будет работать:)
Как же оно там все работает?
Окей, давайте представим, о чем мы думаем когда пишем обычну аппликацию - о том чтобы написать! Нас не волнует в данный момент сколько там памяти осталось, как грузится процессор, не перегревается ли чего-нить. Обо всем этом за нас думает компьютер!
Теперь давайте подымемся на более верхний уровень - Мы пишем приложение для большой корпорации, которое будет испольщованно огромным количеством людей, отделов, компаний. Все это должно хранится в одном месте, данные должны сохраняться, а также все это должно лекго расширятся. Вот тут то и появляются новые загадки и головная боль! Мы должны думать о куче вещей, типа лоад балансера, ДНС, прт этом вы должны контролировать разрешения для разных типов пользователей. Вообщем, чем больше система - тем больше Вам надо думать как оно все будет взаимодействовать.

Windows Azure - делает очень много вещей для Нас:) Вы не будете тратить столько времени на инфраструктуру, как тратили когда управляли своим датацентром. Теперь, когда Вы пишете, аппликацию для крупной компании , и при этом хостите ее в Облаках - Ажур сам решит вопросы связанные с сетью, с восстановлением в случае поломки аппаратуры, и т.д, и т.п. Тоесть Вы сможете полностью сконцентрироваться на напсании аппликации, а не на настройке оборудования.

Фабрика
Помните, я писал про Бога всех машин в Ажуре?:) Именно фабрика им и является!
Давайте сразу разделим два понятия - фабрика и контроллер фабрики. В двух словах - фабрика - это операционная система, в тоже время контроллер фабрики - это ядро этой системы:).

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

Как видим, без контроллера фабрики, в Ажуре вообще мало чего происходит, но также, контроллер занимается тем, что распределяет ресурсы. Он анализирует модель вашего сервиса, сколько и где ресурсов осталось, и на основании этих данных размещает Вае приложение на том или ином сервере.
Кстати, сущностями Ваших сервисов управляет также он. Каждый раз когда мы размещаем Веб роль на ажуре, для каждой веб роли поднимается отдельная виртуальнам машина. Если Ваше приложение вдруг зависло, то контроллер попытается восстановить работу Вашего приложения. По моим наблюдениям - он просто рестартует машину.Перед тем, как захостить Ваше приложение на ВМ, контроллер пропускает ее через ряд тестов, чтобы определить что виртуальнам машина работает хорошо, и что оборудование работает достойно вашего приложения:) Согласитесь, неприятно если Ваше приложение обвалится после 10 минут работы из-за сгоревшегно оборудования.

Моедль сервиса (Service Model)
Помните в прошлом посте, мы задавали два конфигурационных файла? Вооооот. Мы задавали модель сервиса. Тут мы определяем:
а. Конфигурацию того, что есть Наш сервис.
б. Как сервисы коммуницируют друг-с-другом.
в. Сколько экземпляров Ваших сервисов будут крутиться в Ажуре.

Дак *.cscfg очень похож на web.config
Спасибо, кэп, где-то так и есть:) И даже больше, мы можем хранить там свои настроки.
Для этого нужно вначале открыть файл с расширение *.csdef и определить там наш аттртбут:























Как видим я добавил секцию под название ConfigurationSettings с настройкой под названием MyCustomSettingInAzure. Теперь давайте откроем файл с разширением *.cscfg и добавим туда значение нашего параметра:












Как видим значение нашего параметра "ыыы", что сразу показывает Наш интеллект:)

Для того, чтобы считать этот параметр в коде надо написать такую строчку:

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. Дальше будет.

Полезные ссылки:
http://www.microsoft.com/windowsazure/compute/default.aspx - описание web/worker ролей. Цены.

http://www.microsoft.com/windowsazure/offers/#tcoCompare-LB - калькулятор который Вам поможет легко подсчитать TCO вашей аппликации в Windows Azure.

http://www.datacenterknowledge.com/archives/2009/11/18/microsofts-windows-azure-cloud-container/ - статья про датацентры Ажура.

Немає коментарів:

Дописати коментар