Кластер против облака …

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

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

Упражнение первое или “мама, у нас все сломалось”. Везде пишут (ну и я тоже), что системы виртуализации позволяют осуществлять онлайн-миграцию. А как это поисходит вживую?

cloud1

Вот вам пример. В одном окошке я запустил миграцию виртуальной машины с одной ноды “калькуляторного кластера” на другую, а во втором – просто посылал в сторону мигрируемой машины по пакету в секунду. Как видно на скриншоте, время недоступности машины составило 9 секунд. Общее время миграции было около 30 секунд. На настоящих кластерах время недоступности обычно не превышает и половины секунды. Много ли сервисов требуют для себя такого уровня доступности?

Или вот еще один пример, опять же многократно описываемый. Есть сервис, которому не хватает ресурсов.

cloud2

Если посмотрите на правое окошко (там консоль одной из виртуалок), то там openssl показывает, что он может подсчитать только 11 тысяч хешей md2 за 0.15с. А потом команда free докладывает, что памяти всего 256 мегабайт. Одна команда в левом окошке (на ноде) и openssl уже подсчитывает 540 тысяч за 3 секунды (или 27 тыщ за то же время), а памяти стало уже гигабайт. И все это без остановки или перезагрузки сервиса.

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

Для интереса предлагаю прикинуть, сколько потребуется времени и сил, что бы проделать подобное в обычной инфраструктуре. Удобно? Не то слово!

Надо развернуть новый сервер? Легко!

cloud3

17 секунд (калькулятор, да) и у вас есть готовая машина, которой надо только выделить ресурсы.

cloud4

А когда нужда в ней отпадет … секунда и ненужной машины больше нет.

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

Повторюсь, все это сейчас позволяет делать любая система виртуализации.

Но все-таки, чем отличаются облака от кластеров? Ведь они построены на одних и тех же принципах, позволяют делать одно и то же с одним и тем же результатом.

Отличаются они одним. Системой управления всем этим великолепием.

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

Во-вторых, системы управления заточены на разделение ресурсов. В кластере редко возникает необходимость отделить одну группу серверов от другой. В результате все сидят в нескольких VLAN’ах, разрулить которые легко руками. А в облаках тысячи (десятки, сотни – подставьте по вкусу) пользователей, которых надо развести по своим сетям и не давать серверам одного пользователя прямого доступа к серверам другого. Без системы управления, заточенной на облака, подобная затея попросту обречена на провал.

И наконец, облака тащат в себе всю … скажем так, специфику виртуализации. Скажем, для одного сервиса необходимы ноды, которые используют локальное хранилище, да и еще на SSD. А для другого хватит кусочка общего стораджа. Для каждого сервиса есть свои ограничения, требования, правила. И системы управления следят за тем (скажем, при миграциях), что бы каждый сервис работал на ресурсах того класса, который ему выделен, что бы не происходило overselling (или он был с заранее определенными параметрами) и так далее и тому подобное.

Поверьте, все это удержать в голове и рулить этим через консоль или какую-нибудь утилитку – абсолютно нереальная задача.

И вот за вот это вот снятие “головной боли админа” и просят производители денег. А так-то все можно сделать руками и из консоли …

Показометры в студию!

Что первым делом должна делать программа для учета личных финансов? Конечно, показывать нам эти самые финансы. Или говоря другими словами, показывать состояние счета и транзакции по нему.

vsemo_stage3

Счета у нас внутри базы представляют собой классическое дерево, где у каждой веточки есть свой id и id ветки, из которой она растет. Или id и parent_id. Если parent_id=0, то считаем, что этот счет “корневой” и находится на самом верху.

Методов отображения таких деревьев – уйма. Но я на свою голову решил попробовать применить QTreeView. Обложился документацией, нашел парочку хороших статей на хабре … Казалось бы, бери и делай.

Но фигу. QTreeView в Qt – один из немногих компонентов, который сделан “наотъебись”. Практически нулевая документация, какие-то шаманские пляски для выполнения тривиальнейших вещей и так далее и тому подобное. А практически все примеры в интернете написаны в духе “это просто, берем готовую модель и вуаля!”. А как работает эта модель и почему надо это делать так – ноль.

В общем, потратив впустую пару дней с этими морделями, я плюнул на эту хренотень, взял обычный QTreeWidget и банальным рекурсивным поиском заполнил виджет. На всякие заморочки со скоростью я решил начихать, ибо я не верю, что у обычного пользователя будет больше 100-200 счетов, а на этом уровне сходится все. На тестах виджет вполне нормально крутил 10000 счетов без каких-либо пожираний памяти или тормозов процессора.

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

Из того, что не было в предыдущих стадиях так это только то, что добавилась синхронизация таблички rate, в которой хранятся курсы валют. Тут же всплыла проблема: при синхронизации на немощных компьютерах программа сваливается в Application Not Responding. Надо будет куда-нибудь в синхронизацию воткнуть вызов диспетчера очередей. Сменить алгоритм не предлагать, ибо потом некоторые таблички будут расти и расти …

А вот с окошком отображения транзакций получилось все как по книжкам. Там обычная плоская таблица, поэтому QSqlTableModel пришлась впору. И так как документации, примеров и прочего на порядок больше, то и проблем никаких не было. Почти, но об этом позже.

Через некоторое время я переехал на QSqlRelationalTableModel по одной простой причине: у каждой транзакции есть currency_id, которое отвечает за валюту, в которой сделана транзакция. И что бы не мучаться, проще заставить модельку саму выбирать с помощью join нужные значения из таблицы currency.

Во всем этом великолепии меня поджидало только две засады.

Первая заключалась в именах таблиц. Все-таки transaction является ключевым словом и просто так qtшный sql не хотел использовать эту таблицу. Попытка заэскепить имя таблицы как [transaction] не увенчалась успехом. Но на мою радость оказалось, что “transaction” вполне себе хороший идентификатор для qt.

Вторая заключалась в том, что поле для join задается его порядковым номером. То есть мне надо считать, под каким порядковым номером выводится нужное мне поле и задавать его. А функции типа findColumn(name) я не нашел. Можно конечно поизвращаться самому (db.tables никто не отменял), но пока оставлю в качестве todo на будущее.

Наконец, сделал последний штрих: заставил выводить только те транзакции, которые относятся к выделенному счету. Мелочь через setfilter.

Как обычно, исходники тут

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

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

И тулбарчик на андроидах сверху, а на айфонах снизу! И еще ..

Короче, в следующей серии будет гламуризация полученного.

Как самому сделать себе немного облака. Часть вторая.

IMG_8985

Итак, переходим к самому волнующему: под какой системой виртуализации будет работать наше облако? Простой поиск по интернету выдает такие разнообразные варианты, что прямо теряешься.

На самом деле ответ на этот простой: ставьте ту систему, специалисты по которой наиболее доступны вам. Что бы было у кого и с кого спрашивать.

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

Начну с моей любимой: OpenVZ (Коммерческая Virtuozzo). Самая скоростная система, которая по производительности легко уделывает все остальные. Имеет только один, зато толстый минус: позволяет внутри крутить только linux системы.

VMware. Самая старая, дорогая и поддерживаемая система. Есть бесплатные вариант ESXi, но возможностей у него кот наплакал. За деньги можно сделать систему абсолютно любого уровня. Основные минусы: цена и дикая нелюбовь к несертифицированному железу.

Xen. В коммерческом варианте – Citrix. В России я не видел нормальных внедрений, поэтому опыта у меня нет. Зато за рубежом одни из крупнейших провайдеров – Amazon и RackSpace использует именно его.

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

Hyper-V. Продукт от микрософта и заточенный на работу с микрософтовскими же продуктами. Не так давно научился и linux крутить. Дорогой и пока глючный (ну или мне так везет).

VirtualBox. Бесплатная (для десктопа) виртуализация. Но если вам приходится много работать с Solaris или Oracle, то это единственный выбор.

В общем-то и все. Остальные системы пока в слишком зачаточном состоянии.

По функционалу все системы одинаковы. То есть заморачиваться вопросами «а умеет ли эта система что-то, что не умеет другая» абсолютно нет смысла: все необходимое есть. Разница в том, насколько удобно реализованы те или иные возможности.

К примеру, vmware имеет в комплекте конвертор, который позволяет с минимальными усилиями затащить в себя любую физическую машину, работающую под windows или linux. Она же единственная, кто дружит с OS X. Зато OpenVZ позволяет сделать так, чтобы файловая система (и сама виртуалка) была доступна с хост-машины без каких-либо проблем (и при необходимости наоборот). А KVM доступна на любой линукс-машине и позволяет с минимальными телодвижениями запустить образ от других систем. Ну и если у вас целиком вся инфраструктура на продуктах от микрософта, то с помощью Hyper-V вы мигрируете в облака без особых телодвижений.

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

Хинт: нет никакой необходимости делать все на одной системе. Никто не мешает использовать несколько. Да, получится более сложная инфраструктура, но возможно более эффективная.
Ндас, как-то не очень маркетоидно получилось, зато про всех понемногу. Давайте лучше вернемся к приятному: планированию облака.

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

За что борются инженеры?

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

Во-вторых, за число операций в секунду. Для дисков это зовется IOPS, для сети pps. Чем больше операций система может провернуть, тем меньше надо систем для обработки того же объема запросов.
Для этих значений принцип простой: чем больше, тем лучше. И поверьте, борьба за эти циферки идет жесточайшая. Их всегда не хватает. Вообще всегда.

Какие основные методы применяют?

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

Во-вторых, разделение потоков данных. Это тема в большинстве случаев сродни шаманству. Людей, которые понимают, где в обычных с виду систем могут возникать бутылочные горлышки и как их удалять, очень ценят.
Скажем же веб-сервер. Скажем, ему банально стало не хватать производительности. Поднять второй по каким-то причинам нельзя. Что делают в «лоб»? Обычно наращивают производительность. Скажем ставят SSD вместо обычных дисков. Да, производительность возрастет, но не сильно. Специалист «по горлышкам» придет и увидит, что у веб-сервера есть один поток на чтение, когда он отдает запрошенное, один поток на запись, когда он записывает в лог и еще один поток на запись, когда операционная система обновляет время последнего доступа к файлу. В результате достаточно отрубить время доступа (нафиг он на веб-сервере?) и поднять где-нибудь неподалеку сервер для сбора логов, как дисковой подсистеме отвечающей за веб-сервера резко полегчает: она будет работать только на чтение (и никто не мешает ей поставить RO, что бы еще больше облегчить жизнь). А у сервера логов только на запись. Все счастливы и довольны.

Есть и еще одно «шаманство». Обзывается разделением нагрузки по характеру. Скажем, у нас есть бухгалтерия и почта. Бухгалтерский сервер использует паттерн работы с диском «тут посмотрели, тут записали, тут посмотрели, тут записали» (упрощенно конечно). А почта «записали, посмотрели, посмотрели, посмотрели, записали». Причем временные интервалы и расстояния по диску между «посмотрели» и «записали» у обоих систем разные. В результате кэш, который обязан ускорять работу с диском, банально «загрязняется» и работает далеко не так эффективно, как мог бы.

Да, примеры немного наиграны, но и реальность просто отличается большим числом участвующих «переменных».

Ладно, хватит пугать, надо немного рассказать о типичных методах ускорения сети и дисков и встреченных мной (и совершенных тоже) ошибках.

Объединение линков. Как я писал выше, скорости никогда не хватает. Все сетевые штуки умеют объединять несколько сетевых линков в один. Скажем, у вас в сервере есть 4 порта, каждый на 1Гбит. И в коммутаторе тоже образовалось свободное место. Вы берете 4 патч-корда и соединяете их один-к-одному, включаете бондинг (объединяете их в один транк и так далее) и надеетесь, что в результате получите линк на 4Гбит. А в результате получаете тот же гигабит или чуть больше. Любой продвинутый сетевик уже понял, в чем засада. Для остальных: у бондинга много режимов и вариантов. И только некоторые предусматривают возможность распределение нагрузки по всем линкам.

Звезда – наше все. Это любимая и продвигаемая большинством модель построения сети. Если коротко, то все сетевые устройства подключаются к некой системе, которая уже и занимается передачей пакетов от одного устройства к другому. Просто, понятно и … дорого. Штуки, которые способны переваривать десятки и сотни гигабит (Откуда такие цифры? К примеру, одна виртуалка с бухгалтерией легко генерирует поток в гигабит к диску. Это всего-то 100 мегабайт в секунду. Обычный винт легко выдает) и при этом не становиться единой точкой отказа, стоят дорого. Для обычной сети эта модель практически идеальна. Но у облаков все немного по-другому. Скажем, есть очень большой поток данных между серверами хранения. Не к нодам, а тупо между собой. Для репликации, отказоустойчивости и все прочее. Более того, весь поток сосредоточен между серверами одной группы. Так зачем его гонять через коммутатор, когда гораздо выгодней зацепить сервера между собой прямыми линками? Просто из-за такого изменения топологии задержка в линке падает больше чем в 2 раза! И ведь точно такой же поток данных есть и между нодами …

Не все рэйды одинаково полезны. Скажем, нам нужно создать отказоустойчивый сервер хранения. Надо немного, буквально 20 терабайт. Что делает обычный, не «облачный» админ? Берет два сервера, пихает в каждый по шесть дисков на 4 терабайта, запихивает их в raid5 на отдельном контроллере, объединяет сервера и рапортует о готовности. В результате получается тормозной сторадж, который с трудом способен переварить 400-500 мегабайт данных в секунду. Что делает облачный админ? Берет десять дисков по паре терабайт, делает raid0 средствами операционной системы и затем объединяет сервера. Получившаяся шарманка легко берет планку гигабайт в секунду и не дохнет от на порядок больших IOPSов. Да и еще дешевле оказывается. Почему так получилось? Во-первых, облачный админ исключил лишний уровень отказоустойчивости. Зачем его дублировать на уровне дисков, когда он уже есть на уровне серверов? Во-вторых, raid0 сам по себе работает гораздо быстрее raid5, а тут вдобавок данные обрабатывают 10 дисков против 5 (и не надо ждать, пока raid5 завершит запись на всех дисках). И наконец, он освободил ресурсы процессора от расчета всяких контрольных сумм (если кто-то думает, что отдельные raid контроллеры работают быстрее обычного процессора, то он очень сильно заблуждается). Результат: выигрыш в скорости, выигрыш в IOPSах, выигрыш в деньгах! Сплошной профит!

SSD супротив памяти проигрывает всегда! Последнее время пошла мода ставить SSD для кеширования обычных HDD. Для десктопов это реально увеличивает скорость общения с диском. А вот с облаками эта штука практически не дает прироста. Просто из-за того, что слишком хорошо распределена нагрузка и редко когда в SSD попадает то, что можно закешировать. А ставить их пачками – дорого. Но почему-то редко кто додумывается поставить на сервер хранения не жалкие 16-32 гига памяти, а 256 или 512 и оттюнить операционку на максимальное использование кэша. Поверьте, эффект будет заметен невооружённым взглядом.

Но и это не все, над чем придется поломать голову. При переводе систем в облака крайне рекомендую заранее озаботиться в их установке в варианте, который позволяет масштабироваться с минимальными усилиями или исключить ненужное дублирование. Скажем, для систем на базе jboss можно почти расслабиться: он сам умеет находить аналогичные сервера и парралелить работу. Сервера с MySQL достаточно сразу поднимать в не в конфигурации standalone, а master: потом подцепить другой master или slave будет гораздо проще. Резервное копирование осуществлять не с помощью агентов изнутри каждой виртуалки, а централизовано, на сервере хранения.

Хинт: определить, что лишнее, довольно просто. Просто берете и мысленно ставите рядом еще одну точно такую же систему. Общие данные и там и там? Выносим на отдельную виртуалку/общий каталог на сторадже. Один и тот же сервис делает одну и ту же работу с одним набором данных? В отдельную виртуалку! Какой-то внешний сервис приходит регулярно за каким-то данными? Меняем схему, что бы не он приходил, а мы ему отправляли. И так далее и тому подобное.

В результате у вас должно получиться примерно в 3-4 раза больше «облачных» серверов, чем было «физических» сервисов. Но все сервера будут выполнять одну функцию, их будет легко собрать в группы по характеристикам и все они будут довольно легко масштабироваться.

Только заклинаю вас: сразу все определите правила для поименования, нумерации сети и документирования. Нет ничего хуже, чем обозревать сеть с server1, server2, test-server, lama, vanya (брать имена городов, животных, клички ничем не лучше). Поверьте, даже для небольшой компании со временем легко набирается сотня-другая виртуальных серверов. В имени сервера должно присутствовать как минимум указание на его функциональную сущность (например stor, node, app, web), его уникальный номер (хорошо если привязанный к его адресу в сети) и если необходимо, какой-либо другой признак (dev, ivan, test). А за отход от правил тут же и немедленно бить чем угодно. Но еще лучше помогает тупо удаление сервера: второй раз никто такую ошибку обычно не допускает.

И тогда любой при взгляде на stor25fast сможет сказать, что это сервер хранения для требовательных к ресурсам задач с адресом 10.0.0.25, a web40-test-ivan – тестовая машинка с веб-сервером, поднятая Иваном и имеющая адрес 172.16.0.40. Думаю, смысл понятен.

Думаю, я достаточно загрузил вас. Пора немного прерваться.

И да, я опять спер картинку

Как самому сделать себе немного облака. Часть первая.

cloud
Данный текст я решил написать в расчете на ИТшников, которые уже задумались про перевод своей инфраструктуры в «облака» и теперь думают, как же это сделать. На мой взгляд, в интернете слишком много уделяется внимания тому, как надо покупать «облака» (дальше буду без кавычек), а не тому, как их использовать, создавать или как они устроены. Дескать, это сложная наука, подвластная только крутым специалистам с кучей дипломов. Ну или интеграторам с такими специалистами в штате. Стоимость подобных облаков обычно получается какая-то негуманная. А если упомянуть про про bigdata, DWH и прочие слова из буклетиков, то к ценнику добавляется нолик-другой.

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

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

Для начала надо определиться, что же такое облако и с чем его можно есть.

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

Для обычных же людей это некая сущность, которая предоставляет им сервисы по формуле «дешевле, быстрее, надежнее: выбери два из трех». Опять ничего нового.

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

Как-то грустно получается, не находите? Почему же облака так стали популярны? Дело в том, что появились новые методы использования доступных мощностей. И как раз они основаны на сильном упрощении процесса обеспечения тех самых «масштабируемостей», «отказоустойчивостей» и прочего.
В итоге грань между «отказоустойчивым кластером» (масло маслянное, да) и «облаком» получилась … ну очень тонкой. Поэтому предлагаю оставить теологические споры диванным аналитикам и перейти к практике.

Что можно получить от облака?
– Снижение расходов на обслуживание бизнеса. Как прямых, вроде стоимости серверов, так и косвенных, в виде ускорения каких-либо бизнес-процессов.
– Увеличение доступности сервисов. Выйти на «5 девяток» по-прежнему дорого, но гораздо дешевле, чем это было лет пять назад.
– Открытие новых возможностей для бизнеса. Звучит слишком рекламно, но это реально так. Новые технологии реально дают такие возможности, даже заикание о которых раньше приводило к кручению пальцем у виска.

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

Для начала про повышение надежности и снижение стоимости. Откуда это получается? Во-первых, обслуживать настроенные однотипно сервера гораздо проще, чем обычный зоопарк. Одни и те же версии программного обеспечения, одно и то же железо. Это дает выигрыш как во времени работы инженеров, так и позволяет получать скидки от вендоров. Во-вторых, возможность вывести любой сервер из кластера для обслуживания. Просто даем команду системе виртуализации убрать с него все сервисы и спокойно занимаемся необходимым. Тем более такую команду может дать и система мониторинга в случае превышения каких-либо значений типа температуры процессора или скорости вращения вентиляторов. И в-третьих, система мониторинга может дать и другую команду: добавить ресурсов «задыхающемуся» сервису. Думаю, любой ИТшник сразу же найдет кучу применений этим возможностям.

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

Вот я тут упомянул публичные и гибридные облака. Чем они отличаются? Публичное облако – это такое облако, все сервисы которого крутятся у провайдера. Гибридное – это «размазанное» по своим и провайдерским мощностям.

Теперь немного про популярные слова, которые связаны с облаками. И которые связывают с преимуществами для бизнеса.

Вот скажем bigdata. Что это? Я встречал определения типа «это то, для обработки чего не хватит даже самого мощного компьютера» и «петабайты данных». Я сторонник другого, более крамольного определения.Bigdata – это те данные, которые у нас уже есть, но мы не знаем, что с ними можно сделать. А потерять не охота. У кого-то это будет мегатонны логов пользователей, у кого-то куча данных с датчиков а у кого-то это будет жалкая пара терабайт картинок. И вот облака дают возможность как-то хранить и по возможности обрабатывать эти данные. При этом бигдачность системы вовсе не характеризуется объемом обрабатываемых данных. Есть системы, где обрабатываются буквально гигабайты данных, но эти гигабайты легко грузят сотни серверов. В общем, красивое слово.

VDI. Или Virtual Desktop Infrastructure. Развитие идеи терминальных серверов, только с предоставлением пользователю своей виртуальной машины. Шикарно ложится на облака, особенно в случае применения однотипных АРМов и поэтому в последнее время развивается очень сильно.

DWH или Data WareHouse. Еще одно общее слово. Для кого-то это хранилище кучи файлов, кто-то хранит всякие таблички. Говоря кратко, это то место, куда бегают всякие система анализа и отчетов за данными. Данные там собираются из разных источников, приводятся к общем знаменателям, группируются и так далее и тому подобное. По понятным причинам DWH очень любят всякие финансовые компании.

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

Планируем облако.

Что надо сделать в самом начале? В самом начале надо взять за шкирку вашего системного аналитика … как нету аналитика? Тогда берете за шкирку себя и начинаете описывать и считать.

Берете каждый сервис в вашей инфраструктуре и все обдумав, отвечаете на следующие вопросы:

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

– Доступность сервиса. Может ли он делать паузы во время работы? Скажем на 5 минут? Телефония должна работать всегда, а вот резервное копирование может и постоять на паузе.

– Критичность сервиса. Если он «упадет», как сильно это повлияет на бизнес? Сравните бухгалтерию во время сдачи отчета и внутренний портал. Если добудете цифры в духе «простой 5 минут – 100500 рублей» или «день простоя – штраф в мульен», то вообще отлично. Хинт: заручитесь одобрением финансистов и бухгалтеров: они тают, когда ИТшники их спрашивают про их тяжелую долю и пытаются ее облегчить.

– Ресурсные требования по времени. Телефония требует ресурсы пиками и очень не любит, когда ей недодают ресурсов вовремя этого пика. А тот же веб-сервер толерантен к таким проблемам.

– Просто ресурсные требования. Сколько дисков-процессоров-сети надо сервису.

– Сложность обслуживания? Сколько ИТшников в среднем требуется для обслуживания этого сервиса. Стоимость ИТшника?

– Есть ли возможность прогнозировать нагрузку? Для веб-сайта – нет, а для той же системы резервного копирования – запросто.

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

– Возможность вынести сервис наружу. Веб-сайт и почтовые системы – почему бы и нет? Бухгалтерию – убьют.

– Уровень масштабирования в зависимости от роста компании. Веб-сайту пофиг, сколько у вас сотрудников, а той же VDI или почтовой системе – нет.

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

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

Это очень нудная, сложная и муторная работа (хотя и должна быть сделана в рамках ITIL/ITSM). Но в качестве утешения я вам обещаю, что вовремя или после процесса вы обнаружите кучу интересных вещей, которые были раньше скрыты.

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

Но на данном этапе я повангую и скажу сразу: больше всего линий пойдут к двум сервисам – сервису передачи данных (он же обычно обзывается «локалкой») и к сервису хранения данных (он же жесткий диск, он же файлопомойка, в некоторых случаях это будет NAS).

Следующим по числу «использований» будет сервер баз данных. Но большая часть будет с двумя линиями – к серверу приложений и к хранилищу данных. Зато этих серверов баз данных будет много. Веб-сервер, бухгалтерия, мониторинг, чертлысый – и везде какой-нибудь да серверок будет.

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

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

Затем закрашивайте тем же цветом те сервисы, от которых зависит данный сервис. Скажем, если вы пометили, что телефония у вас критичная, то следом должны стать критичными «интернет», «локалка», «фаерволл», «сервер данных о пользователях» и стораджи, на которых все это лежит. Ведь без любого из этих сервисов телефония попросту не будет работать. Скажем, отнимаем интернет или фаерволл – перестаем принимать звонки из внешнего мира. Убираем локалку – пользователи перестанут получать звонки. При закраске необходимо строго соблюдать уровень критичности по повышению – если сервис «критичен всегда», то он не может быть перекрашен или зависим от «критичен только в рабочее время».

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

Следующим шагом необходимо изучить у критичных сервисов механизм масштабирования и его стоимость. Где-то будет все просто: добавляем кучку однотипных сервисов и все будет в порядке. А где-то дешевле ограничиться добавлением аппаратных ресурсов. Тут можно покрасить разным цветом рамки или еще как-нибудь разделить «хорошо масштабируемые» от «плохо».

И я очень надеюсь, что вы использовали visio или что-то подобное. Для понимания текущей ситуации очень полезно сгруппировать сервера по критичности/доступности/расположению (как вам больше нужно).

И наконец, последний шаг. Считаем себестоимость каждого сервиса. Скажем, сколько стоит нам веб-сервер сейчас? А если его в локальный кластер? А сколько будет стоить, если его унести на арендованный у провайдера сервер? А если под него купить облако? Есть ли загружаемые с веб-сервера большие файлы, под которые дешевле будет купить сервис CDN? Есть ли разница в стоимости лицензий для «standalone» и «cloud/terminal»? Если мы уменьшим время простоя, то сколько сэкономим?

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

Теперь необходимо причесать картинку и полученную табличку, чтобы получить практически непотопляемые аргументы для любого совета директоров/ акционеров/ финансистов/ ещекого. Эти люди по роду своей деятельности очень любят картинки, которые подкреплены реальными цифрами.

Наиболее внимательные сразу отметят один очень важный момент, который вроде нигде не упомянут: а как выбирать систему виртуализации? Ведь ее тоже необходимо закладывать в бюджет.

Скажу сразу, выбирать систему виртуализации еще рано, в следующей части будем. Вы для начала докажите себе и владеющим деньгами людям, что это вообще выгодно будет. Для предварительных расчетов можете смело ставить стоимость системы виртуализации в 300 баксов на один железный сервер. Этого при необходимости хватит на корпоративную и пальцатую VMware, но скорее всего можно будет обойтись гораздо меньшими деньгами. Лучше побольше заложите на инженеров. Чем он будет более «продвинутей», тем больше шансов, что у вас все взлетит.

И да, картинку спер из интернета. Автора не знаю, а то бы написал.

Продолжаю всёмоёшить …

Итак, продолжаем делать клиента.

Как ни обидно будет читать некоторым, но мне пришлось отказаться от QML. Слишком сырая штука для подобных проектов. Во-первых, делать связку между C++ и QMLной частью – это еще тот секс, а без подобных связок никак. Во-вторых, отсутствие нормальных layout менеджеров ставит полностью крест на кросс-платформенной разработке. Это я понял после того, как для странички логина у меня получился огромный и безформенный кусок спагетти, отвечающий за положение элементов в разных средах и формах. И наконец, вся эта машинерия у меня внезапно сглючила. Например, у меня поля ввода перестали убирать при вводе placeholder и стали оставлять после себя артефакты. И это даже при использовании специальной “чистой” сборочной виртуалки. И под виндовсом и под OS X.

В общем, плюнул я на борьбу с мельницами и вернулся к обкатанным QWidgets.

Сейчас в Stage2 реализовано следующее:

stage2

Желтеньким выделено реализованное. Белое я оставил, ибо после размышления я решил, что нефиг этому функционалу делать на окне логина. За кадром остался функционал работы с сетью, базами данных и синхронизацией.

И что больше всего радует, на всех платформах оно работает! И работает довольно шустренько. К примеру, скорость процесса синхронизации не сильно отличается от десктопной.

Что вскрылось в процессе написания и что может быть вам полезно.

Во-первых, забудьте про всякие QDialog и все связанное с ним (QMessageBox и теде). Только QMainWindow для всего. Причина простая – на андроиде и айпаде окошко зажимается в левом верхнем углу и никак его оттуда не вытащить без трахтибидоханья. QMainWindow ведет себя гораздо более приличней и плюс позволяет с собой поделать всякие кунштюки типа сохранения координат-размеров. Да, придется немного помучаться, зато потом оно летает без геморроя.

Во-вторых, вам придется переопределить все методы show и вручную написать для каждого элемента что-то типа ui->element->adjustSize(); без них вы на мобильных платформах с большим dpi получите малюсенькие элементы управления, в которых будут проглядывать надписи.

И наконец, забудьте про пикселы и прочие ldpi. Все в платформонезависимых единицах, типа пунктов для шрифтов. Всякие кнопки и прочие элементы управления – загоняйте в layout. Отдайте это на откуп Qt – у него очень неплохо получается.

Как обычно, полученное доступно тут. Дизайну ноль, зато весь функционал работает.

Теперь пора переходить к главному окну приложения. Но это в следующих постах.