четверг, 2 июля 2009 г.

Облако без штанов или Приходит Cloud Computing

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

Если взглянуть на развитие событий сверху, с птичьего полета, то можно заметить некоторые моменты, давно и хорошо знакомые Настоящим Айтишникам.

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

(Масштабов задачи на этот раз, однако, ни один бизнесмен даже представить себе не в состоянии. Особенно в случае попытки массового применения технологии. Равно как и ураганного количества проблем по отношению к решениям. По-моему, даже масштабы Веб 2.0 оказались сюрпризом для матерых вендоров, и лишь лавина денег, притекающая буквально из ниоткуда, не дает им испугаться и убежать)

Как IPv6. "IP-адрес - каждой кофеварке!"

(С IPv6 вообще веселая история. То, что новая система адресации фактически требует кардинально другого мышления и совершенно нетривиальна даже для седых сетевиков - это еще полбеды. Но как они собираются управляться с миллиардами адресов, абсолютно любых устройств (отдельный риторический вопрос - зачем любому устройству IP-адрес), даже с учетом сократившихся таблиц маршрутизации - и проделывать это без ИИ - сие за пределами моего понимания)

Вендоры дружно ринулись осваивать новое пространство, не задумываясь о том, чем, собственно, все это может быть чревато и, в особенности, годится ли новая технология для всего на свете.

Этакий философский камень, алкагест и панацея в одном флаконе. "Открываемая" каждые три-четыре года.

NetPC. Кластеры. Grid computing - кстати, найдите 10 различий с Cloud computing - и RAC.

Нет, с точки зрения наличия костылей, и на первый взгляд, технология облаков вроде бы значительно стройнее концепции гридов и RACов. Однако только на первый взгляд.

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

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

В свое время на этом не по-детски обожглись апологеты RAC - "Не надо переписывать приложения - они будут работать как раньше!"

Что, мальчики и девочки, очередная "новая" чудо-технология сумрачных гениев раз и навсегда порешала ваши проблемки?

Или бородатый сисадмин с живым и, главное, действующим головным мозгом по-прежнему суть единственная сила, способная к решению проблем?

Второе. Все это было бы чрезвычайно забавно, если бы не было настолько грустно. Абсолютно узкоспециализированное решение виртуализации и концепции вычислительных суперкластеров тащат в сферу бизнес- и Интернет-приложений. Причем ежу понятно, что идея "Resources on demand" совершенно не нова. Так же ежу понятно, что, хотя концепция виртуальных систем и восходит к безопасности, и управляемости, однако в облаке (в силу огромной концентрации ресурсов и приложений в одном флаконе) будет совершенно нереально обеспечить единую модель безопасности - даже с применением гипервизоров и контейнеров, а так же нереально обеспечить единообразное распределение приложений по физическим ресурсам (что понравится далеко не всем приложениям, например, совершенно неясно, как будет осуществляться привязка приложений - affinity - с критичным временем отклика - к одним и тем же ресурсам облака). Для вычислительных задач это практически не имеет значения, но мир IT состоит главным образом не из вычислительных задач - соответственно, so what?

Да, Amazon это использует. В своей весьма специализированной сфере. Использует всего ничего, чтобы трубить в фанфары и кричать об очередной "победе разума над сарсапариллой". Рано пока еще о чем-то говорить. И я практически уверен, что неспециализированных приложений в облаках Амазон нет и пока не предвидится.

Но что мне абсолютно непонятно, так это третье.

Третье. Если и есть какая-то математическая модель и теория облачных вычислений - она мне неизвестна. Как всем этим управлять?

В теории - концепция cloud computing, пожалуй, ближе всего к MPP - массивно-параллельным архитектурам. NB - примите во внимание тот факт, что удовлетворительной и полной теории, пригодной к употреблению, для MPP за все время существования подобных систем создать как-то не удалось.

Четвертое. А как всем этим управлять? Администрирование - оно что, будет осуществляться ИИ , который самозародится в этой огромной куче компьютерных систем?

Может быть, администрировать облака будут сами клиенты таких систем? Делать резервные копии, устанавливать политики безопасности, настраивать управление ресурсами?

Что, непонятно, что при подобной концентрации ламья, собранного по принципу "платите - и нам пофигу, что вы будете делать" в среде облаков будут как рыбы в воде плескаться хакеры? Потроша клиентов? Ах, да - виртуальные системы неуязвимы, OpenSource спасет гигантов мысли, шифрование вообще решает все проблемы...

Нужно ли напоминать, что при подобной концентрации ресурсов сломать какой-нибудь хэш будет раз плюнуть, организовав для этого ботнет (И какой ботнет можно состряпать!) просто не сходя с места, а про легко вычисляемые пароли я просто умолчу?

Все вышеприведенные ссылки на тему безопасности лично меня убеждают точно так же, как WEP в Wi-Fi.

Кстати, и здесь история воспроизводится с точностью до.

Сперва родили технологию, выпустили джина из бутылки ее на рынок, а затем ломанулись дорабатывать, обнаружив, что, оказывается, и криптография слабовата, и аутентификация не бог весть что, да и вообще - нафига мы это сделали? Wardriving задолбал!

Но, как заявляют апологеты - как круто, сидя утром на унитазе, читать на iPhone новости по Wi-Fi!

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

Такое гордое слово "прогресс".

Однако я отвлекся.

Чем особенным может похвастаться облако?

Да ничем особенным. В настоящее время видно лишь типичную маркетинговую возню и скороспелые (и абсолютно волюнтаристские) заявления вендоров, которые наперебой уверяют, что у них-то и есть единственное ULTIMATE-решение, полностью готовое, я цитирую дословно рекламную рассылку одного вендора - "Cloud computing promises a lot - and it will deliver".

Все это именно что promises. Будет ли deliver - еще бабка надвое сказала.

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

И для этого у меня есть все основания.

Infrastructure as a Service (IaaS) - не завершенная и всеохватывающая теория с решением. Это не более, чем architectural approaches.

Я, кстати, как-то плохо представляю себе чудо-архитектуру (интересно, на каких реальных технологиях планеты Земля можно реализовать решение всех проблем, как обещается?), об approaches которой идет речь.

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

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

Потому что облака, в частности, содержат или могут содержать кластеры. Не просто это однородная плоская сеть тысяч серверов и сториджей, работающая без коллизий, собранная идеально, и управляемая ИИ.

Quality этого самого IaaS вызывает большие сомнения в связи с affinity приложений и процессов, с существующими ограничениями Ethernet (который ныне суют куда надо и куда не надо), IPv4 (а жизнеспособность IPv6 лично для меня все еще под очень большим сомнением) и другими инженерными ограничениями.

Опять же, мальчики и девочки - законы сохранения никуда не делись. Питание-охлаждение-отказоустойчивость-управление-производительность. Вы точно уверены, что серверов станет меньше и глобальное потепление перестанет клевать зеленых в задницу? А системных администраторов перестанут клевать в голову проблемы управления, а начальство в печень? А облака из строя не выходят?

Это ничего, что просто по закону больших чисел вероятность отказа такой чертовой кучи оборудования (даже если это оборудование HA-класса) сильно отличается от нуля в сторону увеличения?

Это ничего, что закон Амдала-то действует и производительность в идеальном случае просто не вырастет?

А еще у меня есть реальные сомнения (с учетом вышесказанного), что перестав оплачивать собственную IT-инфраструктуру, потребители не станут платить больше за IaaS.

Убедительных расчетов "затраты - выигрыш" и "жирная разница со знаком плюс, которая может заинтересовать мистера Роллинга" лично я не видел.

Только маркетинговая трескотня да кивания гривой в сторону Амазона. Который-де всем доволен и вообще побеждает (надо заметить, что он убедительно побеждал и безо всяких там облаков).

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

Сначала SAN.

Физически одиночный узел SAN представляет из себя как правило не слишком суровый серверок с кучей подключенных напрямую дисков, на которых развернут software RAID. Обычно не слишком навороченный (деньги-деньги-дребеденьги). Обычно не слишком настраиваемый. Обычно слишком обобщенный, чтобы быть реально быстрым (оставим пока в покое системы хранения Hi-End класса - там другие порядки стоимости и другая цена вопроса).

Этот самый серверок доступен по Ethernet. Несколько гигабитных интерфейсов. Либо 10 Гбит Ethernet (все помнят, сколько стоят такие интерфейсы?).

Кстати, о 10 Гбит Ethernet. Для того, чтобы реально загрузить подобную карточку на 100% вводом-выводом, требуется совсем даже не полная мощность одного процессора. Так, для информации.

Даже четыре гигабитных интерфейса требуют полного внимания четырех-восьми ядер.

И все это помимо того, что Ethernet принципиально не предназначен для упорядоченной потоковой передачи информации, как, например, SCSI/SAS. О чем речь пойдет во втором примере.

Умолчим также о том, что усложнение системы крайне редко приводит к увеличению ее надежности - аксиома, известная каждому инженеру. Кластерщики, использующие т.наз. HA-кластеры могут не согласиться со мной, однако реальность несколько отличается от желаний и мечтаний. Впрочем, айтишники не вполне нормальные инженеры и законы физики и постулаты реального мира им, как правило, неизвестны - даже после нескольких крупных попадаловых.

Теперь то, что часто используют в SAN - iSCSI.

Еще один шедевр инженерной мысли (а на деле феерический костыль костылей), творение сумрачных гениев, вундер-технология, решающая все и вся.

Те, кто реально работал с iSCSI, знает, насколько непригоден TCP/IP+Ethernet для замены FC-AL/SAS/SCSI.

Прежде всего, низкая надежность. Малейшая контактная проблема - и iSCSI-устройство отлетает на полном скаку от сервера, который с ним работает. Зачастую толстый полярный лис прямо в этот момент подстерегает файловую систему. Прошу заметить - введение свича в систему (а это принципиально понадобится, скажем, при использовании Link Aggregation и множественном, например, кластерном доступе к shared file system) проблемы не решает и решить принципиально не может, ибо количество RJ-45 физически даже не удваивается, а утраивается. Электроника - наука о контактах.*

В моей практике был случай, когда подобная проблема разнесла в клочья ZFS-пул на массиве с iSCSI, содержащий около 1 Тб данных БД Oracle. И только физический бэкап спас гиганта мысли.

Про скорость даже топового массива, соединенного по iSCSI (все фичи включены - Link Aggregation, Jumbo Frame итд.итп.) я деликатно умолчу.

Выделенный массив с FC-AL еще долгое время будет рвать в клочья iSCSI. Ибо покупать карточки 10 Гбит Ethernet, во первых, адски дорого, а, во-вторых - вместе с ними можно сразу бежать за дополнительными процессорами.

К чему я привожу все эти примеры и куда я, черт побери, клоню?

А вот куда. Обе эти технологии (а как вы представляете себе огромное количество ввода-вывода, ибо не вычислениями едиными живет современный мир IT?) в полной мере используются в облаках.

Выводы может сделать каждый, оборудованный головным (а не только спинным) мозгом.

PS. Судя по развитию событий, не больно-то IT-мир бросился потреблять новую чудо-технологию. Раз требуется стучаться в каждое доступное окошко. И каждый раз подчеркивать, что "Облака могут быть и приватными". Что тоже достаточно красноречиво, не правда ли?
______________________________________
* И прошу также заметить, что речь не только и не столько о физике. TCP/IP - протокол, принципиально предназначенный вовсе не для дисковых обменов на высокой скорости с гарантированной доставкой и полной защитой данных при передаче. А это означает, что, скажем, corrupt-блоки будут появляться просто как из-под земли, скажем, в случае коллизий в сетевой среде при перегрузке. Или пакеты будут бесследно пропадать в "черных дырах" при плохой маршрутизации. Или данные будут разрушаться при любом искажении при передаче (например, умышленном или в случае проблем с оборудованием, при наводках электросети итп.), от которых, как известно, TCP/IP вовсе не предохраняет.