Открытие Облака Для Новых Клиентов

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

Тарифы те же, возможностей больше.



Открытие облака для новых клиентов

Ключевые изменения:

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

  • Снимки
  • Улучшена производительность панели управления.

Собственно, на этом анонс заканчивается, затем начинается текст. Что мы делали эти 3 месяца? Или, правильнее, «что случилосьЭ» Замечательный язык Python известен как превосходный инструмент быстрой разработки.

Написать на нем прототип работающего приложения, «пруф-концепт» — да.

Написать на нем приложение, которое больше времени тратит на библиотечный код, чем на математику — да.

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

До определенного момента это возможно.

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

Именно такая ситуация произошла с нами.

При этом были обнаружены узкие места в нескольких компонентах, которые были «написаны и забыты» (то есть не запланированы к дальнейшему развитию в ближайшем будущем).

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

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

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

В тот момент, когда некоторые API-запросы стали выполняться по 10 секунд вместо положенных 0,1-0,2 (кто-то мог заметить, как медленно в этот момент отображалось содержимое панели управления, причем задержка была совершенно непредсказуемой), было принято решение прекратить создание новых машин.

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

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

Или, другими словами, мы обратились к функциональным языкам программирования.

А именно, язык программирования Haskell. Да-да, тот страшный и ужасный язык, в статьях о котором на страницах 5-10 заканчивается код и начинается высшая математика.

Лично я был категорически против принятия этого языка.

Однако аргументы сторонников меня убедили - строгая типизация, вывод типов, сопоставление с образцом (с контролем его полноты).

Добавим к этому потребительские свойства: компилируемый язык (читай: для запуска нужен только исполняемый файл без какого-либо окружения), долгая история с давними детскими болезнями (20+ лет), множество библиотек на все случаи жизни (это , кстати, определил «Haskell или okaml»).

Что меня окончательно поразило, так это то, что программа на Haskell сравнялась в простом тесте ввода-вывода и математики с программой на C. Более того, «нос к носу» — это с gcc оптимизация включена.

Быстро ли программировать на Haskell? Нет. По моим наблюдениям, программа пишется примерно в три раза медленнее, чем на Python. Однако настоящая разница наступит позже.

Достаточно сказать, что если для Python-программ мы выкатили в продукт в среднем от 3 до 10 исправлений, то программы, которые мы сейчас запускаем на Haskell, практически не содержат исправлений.

Большая часть изменений связана с изменениями в технических характеристиках, а не реакцией на очередное «attribute has not Method foobar» в трассировочном журнале.

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

Более того, напоследок — наш API-сервер по-прежнему написан на Python — и именно «быстрый Python» стал причиной двухнедельной задержки запуска, так как нам пришлось неоднократно и мучительно перепроверять все варианты поведения нового функции, которые Python (как динамически типизированный язык) не мог проверить.

… Однако пока программисты оттачивали свой стиль, отдел системного администрирования не сидел на месте.

Кластерное хранилище

Открытие облака для новых клиентов

Одним из наших недостатков было использование некластеризованных систем хранения.

Данные были в безопасности, но была вероятность столкнуться с проблемами безотказной работы.

Не очень большой, но он был.

Надеемся, что сочетание drbd, flashcache и multipath решило эту проблему.

Данные хранятся в 10 рейдах, полная копия всех данных находится на каждом узле кластера.

Если узел умирает, клиенты либо ничего не замечают, либо (в худшем случае) получают задержку в дисковых операциях на 5-10 секунд, после чего multipath находит альтернативный путь и запросы дальше обрабатываются без сбоев.

Шаблоны.

Ключевым и принципиальным моментом стал переход на ядро 3.1-xen (кроме Centos, который сам по себе).

При этом мы, неохотно, разрешили пользователям загружать ядра с машины, а не «наши».

Почему неохотно? Потому что если клиент установит «не то ядро», его машина зависнет или будет вести себя неадекватно.

Бедный, бедный отдел технической поддержки.

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

Вторым важным изменением стал переход на LVM для системных дисков.

Это должно значительно упростить процесс управления разделами.

Обновлены ОС: появились OpenSUSE 12.1, CentOS 5.7, Debian Wheezy. Появился шаблон с ClearOS (для тех, кто хочет веб-интерфейс к VPN-серверу).

Еще несколько полезных шаблонов находятся в разработке.

Снимки

Открытие облака для новых клиентов

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

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

* Снимки хранят только измененные данные (минимальный размер - 8 МБ) * Снимки оплачиваются как дисковое пространство (отдельная строка) по цене обычного дискового пространства.

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

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

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

Кроме того, мы переписали статистику и существенно снизили нагрузку на базу данных по некоторым типам запросов.

Заодно втихаря добавили экспорт данных о потреблении в CSV. Много времени было уделено эргономике.

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

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

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

Кстати, если у кого-то в каком-то случае возникло явное ощущение «слишком много дел» — пишите мне (или в тикеты).

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

Судьба старого пула.

Из-за архитектурных изменений нам не удалось реализовать новые функции в старом пуле; они реализованы в новом пуле (в нем будут созданы виртуальные машины).

  • Ссылка: пул (pool) — группа серверов с единым административным центром (мастером пула), имеющая единую конфигурацию и общее хранилище.

    В нашем контексте облако означает высшую иерархическую единицу сегментации облака.

    Пулы не взаимодействуют друг с другом, хотя подчиняются единому API-серверу.

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

Теги: #selectel #cloud #cloud #announcement

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.