Новость одной строкой:
Ключевые изменения:
Собственно, на этом анонс заканчивается, дальше начинается лирика.
Чем мы занимались эти 3 месяца?
Или, правильнее сказать, «что было не так?».
Замечательный язык python славится как отличное средство rapid development. Написать на нём прототип работающего приложения, «доказательство возможности» (proof of concept) — да. Написать на нём приложение, которое больше времени проводит в коде библиотек, чем над математикой — да.
Но вот писать на нём многопоточные приложения с десятками тысяч транзакций в секунду с разумным потреблением процессора… До определённого момента можно. Дальше начинаются архитектурные проблемы, на борьбу с которыми начинает уходить больше времени, чем на программирование нового.
Именно такая ситуация у нас и случилась. Одновременно в нескольких компонентах, которые были «написаны и забыты» (то есть не планировались к дальнейшему развитию в течение ближайшего времени) обнаружились боттлнеки. Некоторое время мы «развлекались» оптимизацией кода, обсуждали возможность вынесения его части в сишные библиотеки с биндингами на питоне… Пока мы не обнаружили, что проблемы копятся быстрее, чем мы их решаем. И это не смотря на то, что этой осенью мы практически удвоили число разработчиков.
Дополнительную проблему создавали новые пользователи, экспериментирующие и играющие с функционалом (мы ничего не имеем против, но не в тот момент, когда система и так «на грани») — это давало дополнительный стресс. В тот момент, когда некоторые API-запросы стали выполняться 10 с вместо положенных 0.1-0.2 (кто-то мог заметить, как медленно в тот момент отображалось содержимое панели управления, причём задержка была совершенно непредсказуемая), было принято решение прекратить создание новых машин.
Это во-первых снизило нагрузку от новых клиентов, во-вторых, когда все машины созданы, пользователи редко заходят в панель управления и число обращений к панели управления значительно упало.
В то время, когда стабилизировалась нагрузка, в ходе крайне кровавых боёв функционалисты победили процедурщиков. Или, другими словами, мы посмотрели в сторону функциональных языков программирования.
А именно, на язык программирования Haskell.
Да-да, того страшного и ужасного языка, в статьях про который на 5-10 странице заканчивается код и начинается высшая математика.
Лично я был отчаянным противником принятия этого языка. Однако, аргументация со стороны сторонников меня убедила — строгая типизация, выведение типов, паттерн матчинг (с контролем полноты оного)…
Добавим к этому потребительские свойства: компилируемый язык (читай: для запуска нужен только исполняемый файл без всякого окружения), долгая история с давно пройденными детскими болезнями (20+ лет), масса библиотек для всех случаев жизни (это, кстати, определило «хаскел или окамл»). Окончательно меня сразило то, что программа на хаскеле шла нос-в-нос в простеньком тесте на IO и математику с программой на Си. Причём «нос-в-нос» — это при включенной оптимизации gcc.
Быстро ли программировать на haskell? Нет. По моим наблюдениям программа пишется примерно в три раза медленнее, чем на питоне. Однако, настоящая разница приходит после. Достаточно сказать, что если для программ на питоне мы выкатывали в продакт в среднем от 3 до 10 багфиксов, то те программы, которые у нас сейчас работают на хаскеле, багфиксов практически не содержат. Большинство изменений связано с изменением ТЗ, а не реакцией на очередное «attribute has not method foobar» в трейслоге.
Раньше мы писали много кода на питоне, теперь мы пишем мало кода на хаскеле.
Всё ли мы переписали на хаскел? Увы, нет, процесс идёт по мере возникновения потребностей и большая часть нашего кода всё ещё на питоне, но по мере изменения архитектуры всё остальное планируется переписать на него.
Более того, как финальный аккорд — наш сервер API всё ещё написан на питоне — и именно «быстрый питон» стал причиной двухнедельной задержки с запуском, так как пришлось многократно и болезненно перепроверять все варианты поведения новых функций, которые питон (как язык с динамической типизацией) проверить не мог.
…
Впрочем, пока программисты оттачивали стиль, отдел системного администрирования не сидел на месте.
Одним из наших недостатков было использование некластеризованных СХД. Данные были в безопасности, а вот вероятность наткнуться на проблемы с аптаймом была. Не очень большая, но была.
Сочетание drbd, flashcache и multipath, надеюсь, решило эту проблему. Данные хранятся на 10ых рейдах, полная копия всех данных располагается на каждом узле кластера. Если узел умирает — клиенты либо не замечают ничего, либо (в худшем случае) получают 5-10 с однократную задержку дисковых операций, после чего multipath находит альтернативный путь и запросы дальше обрабатываются без сбоев.
Вторым важным изменением стал переход на LVM для системных дисков. Это должно значительно упростить процесс управления разделами.
Обновились ОС: OpenSUSE 12.1, CentOS 5.7, появился Debian Wheezy. Появился шаблон с ClearOS (для тех, кому хочется веб-интерфейса к VPN-серверу). Ещё несколько полезных шаблонов в разработке.
Самая сложная и трудная задача, которую мы решили с великим успехом. Про снапшоты и принципы их работы я напишу отдельную статью, но вот пока «выжимка» из фич снапшотов:
* Снапшоты делаются «на ходу» без остановки машины
* Снапшоты могут образовывать как хронологический список, так и «дерево».
* Снапшоты хранят только изменённые данные (минимальный размер — 8Мб)
* Оплачиваются снапшоты как дисковое пространство (отдельная строчка) по цене обычного дискового пространства
* Снапшоты диска можно подключать в read only к существующим машинам без прекращения использования «обычного» диска.
Для того, чтобы сделать это хорошо и удобно нам пришлось очень сильно переписать обычные снапшоты в Xen Cloud Platform, в частности, добавить поддержку древовидных отношений между снапшотами и возможность свободных откатов между любыми снапшотами.
Много времени было уделено эргономике. Например, такие поля как пароль, IP-адрес и другие данные, которые часто копируются, сделаны таким образом, чтобы двойной клик выделял их и только их, не заползая на соседей. Все элементы управления в обычных меню являются статичными (то есть не прыгают туда-сюда и не меняют значение в зависимости от контекста). Это не относится к «опасным операциям», где основной нашей задачей было не создать максимум удобств, а заставить задуматься «хочу или нет». Кстати, если у кого-то в каком-то случае возникает явное ощущение «слишком много делать» — пишите мне (или в тикеты). Исправление не обещаем, но я, как минимум, задумаюсь о том, как это реализовать и если получится придумать, сделаем.
Мы будем продолжать поддерживать старый пул длительное время (не обещаю, что «всегда», но весьма долго — точно), а все новые машины будут создаваться в новом пуле — именно там будут работать снапшоты, «нативные ядра» и именно там находятся новые шаблоны.
Облако запустили
Мы снова открыли возможность создавать виртуальные машины и готовы принять новых пользователей в нашем облаке в новом пуле. Тарифы те же, возможностей больше.
Ключевые изменения:
- Новая кластерная СХД
- Обновлённые шаблоны виртуальных машин на LVM, упрощающие изменение размеров диска
- Снапшоты
- Улучшенная производительность панели управления
Собственно, на этом анонс заканчивается, дальше начинается лирика.
Чем мы занимались эти 3 месяца?
Или, правильнее сказать, «что было не так?».
Замечательный язык python славится как отличное средство rapid development. Написать на нём прототип работающего приложения, «доказательство возможности» (proof of concept) — да. Написать на нём приложение, которое больше времени проводит в коде библиотек, чем над математикой — да.
Но вот писать на нём многопоточные приложения с десятками тысяч транзакций в секунду с разумным потреблением процессора… До определённого момента можно. Дальше начинаются архитектурные проблемы, на борьбу с которыми начинает уходить больше времени, чем на программирование нового.
Именно такая ситуация у нас и случилась. Одновременно в нескольких компонентах, которые были «написаны и забыты» (то есть не планировались к дальнейшему развитию в течение ближайшего времени) обнаружились боттлнеки. Некоторое время мы «развлекались» оптимизацией кода, обсуждали возможность вынесения его части в сишные библиотеки с биндингами на питоне… Пока мы не обнаружили, что проблемы копятся быстрее, чем мы их решаем. И это не смотря на то, что этой осенью мы практически удвоили число разработчиков.
Дополнительную проблему создавали новые пользователи, экспериментирующие и играющие с функционалом (мы ничего не имеем против, но не в тот момент, когда система и так «на грани») — это давало дополнительный стресс. В тот момент, когда некоторые API-запросы стали выполняться 10 с вместо положенных 0.1-0.2 (кто-то мог заметить, как медленно в тот момент отображалось содержимое панели управления, причём задержка была совершенно непредсказуемая), было принято решение прекратить создание новых машин.
Это во-первых снизило нагрузку от новых клиентов, во-вторых, когда все машины созданы, пользователи редко заходят в панель управления и число обращений к панели управления значительно упало.
В то время, когда стабилизировалась нагрузка, в ходе крайне кровавых боёв функционалисты победили процедурщиков. Или, другими словами, мы посмотрели в сторону функциональных языков программирования.
А именно, на язык программирования Haskell.
Да-да, того страшного и ужасного языка, в статьях про который на 5-10 странице заканчивается код и начинается высшая математика.
Лично я был отчаянным противником принятия этого языка. Однако, аргументация со стороны сторонников меня убедила — строгая типизация, выведение типов, паттерн матчинг (с контролем полноты оного)…
Добавим к этому потребительские свойства: компилируемый язык (читай: для запуска нужен только исполняемый файл без всякого окружения), долгая история с давно пройденными детскими болезнями (20+ лет), масса библиотек для всех случаев жизни (это, кстати, определило «хаскел или окамл»). Окончательно меня сразило то, что программа на хаскеле шла нос-в-нос в простеньком тесте на IO и математику с программой на Си. Причём «нос-в-нос» — это при включенной оптимизации gcc.
Быстро ли программировать на haskell? Нет. По моим наблюдениям программа пишется примерно в три раза медленнее, чем на питоне. Однако, настоящая разница приходит после. Достаточно сказать, что если для программ на питоне мы выкатывали в продакт в среднем от 3 до 10 багфиксов, то те программы, которые у нас сейчас работают на хаскеле, багфиксов практически не содержат. Большинство изменений связано с изменением ТЗ, а не реакцией на очередное «attribute has not method foobar» в трейслоге.
Раньше мы писали много кода на питоне, теперь мы пишем мало кода на хаскеле.
Всё ли мы переписали на хаскел? Увы, нет, процесс идёт по мере возникновения потребностей и большая часть нашего кода всё ещё на питоне, но по мере изменения архитектуры всё остальное планируется переписать на него.
Более того, как финальный аккорд — наш сервер API всё ещё написан на питоне — и именно «быстрый питон» стал причиной двухнедельной задержки с запуском, так как пришлось многократно и болезненно перепроверять все варианты поведения новых функций, которые питон (как язык с динамической типизацией) проверить не мог.
…
Впрочем, пока программисты оттачивали стиль, отдел системного администрирования не сидел на месте.
Кластерная СХД
Одним из наших недостатков было использование некластеризованных СХД. Данные были в безопасности, а вот вероятность наткнуться на проблемы с аптаймом была. Не очень большая, но была.Сочетание drbd, flashcache и multipath, надеюсь, решило эту проблему. Данные хранятся на 10ых рейдах, полная копия всех данных располагается на каждом узле кластера. Если узел умирает — клиенты либо не замечают ничего, либо (в худшем случае) получают 5-10 с однократную задержку дисковых операций, после чего multipath находит альтернативный путь и запросы дальше обрабатываются без сбоев.
Шаблоны
Ключевым и фундаментальным стал переход на ядро 3.1-xen (кроме центоса, который сам себе на уме). Заодно, скрепя сердце, мы разрешили пользователям грузить ядра из машины, а не «наши». Почему скрепя сердце? Потому что если клиент поставит «неправильное ядро», то его машина будет зависать или вести себя неадекватно. Бедный, бедный отдел технической поддержки. Но удобство от того, что ядро установлено внутри виртуалки всё же перевесило.Вторым важным изменением стал переход на LVM для системных дисков. Это должно значительно упростить процесс управления разделами.
Обновились ОС: OpenSUSE 12.1, CentOS 5.7, появился Debian Wheezy. Появился шаблон с ClearOS (для тех, кому хочется веб-интерфейса к VPN-серверу). Ещё несколько полезных шаблонов в разработке.
Снапшоты
Самая сложная и трудная задача, которую мы решили с великим успехом. Про снапшоты и принципы их работы я напишу отдельную статью, но вот пока «выжимка» из фич снапшотов:
* Снапшоты делаются «на ходу» без остановки машины
* Снапшоты могут образовывать как хронологический список, так и «дерево».
* Снапшоты хранят только изменённые данные (минимальный размер — 8Мб)
* Оплачиваются снапшоты как дисковое пространство (отдельная строчка) по цене обычного дискового пространства
* Снапшоты диска можно подключать в read only к существующим машинам без прекращения использования «обычного» диска.
Для того, чтобы сделать это хорошо и удобно нам пришлось очень сильно переписать обычные снапшоты в Xen Cloud Platform, в частности, добавить поддержку древовидных отношений между снапшотами и возможность свободных откатов между любыми снапшотами.
Панель управления
Дизайн новой панели управления мы «выкатили» незадолго до приостановки обслуживания (глупо, да, но теперь его могут увидеть все желающие). Кроме того, мы переписали статистику, значительно уменьшили нагрузку на БД в некоторых типах запросов. Заодно, под шумок, мы добавили выгрузку данных по потреблению в CSV.Много времени было уделено эргономике. Например, такие поля как пароль, IP-адрес и другие данные, которые часто копируются, сделаны таким образом, чтобы двойной клик выделял их и только их, не заползая на соседей. Все элементы управления в обычных меню являются статичными (то есть не прыгают туда-сюда и не меняют значение в зависимости от контекста). Это не относится к «опасным операциям», где основной нашей задачей было не создать максимум удобств, а заставить задуматься «хочу или нет». Кстати, если у кого-то в каком-то случае возникает явное ощущение «слишком много делать» — пишите мне (или в тикеты). Исправление не обещаем, но я, как минимум, задумаюсь о том, как это реализовать и если получится придумать, сделаем.
Судьба старого пула
В силу архитектурных изменений мы не смогли реализовать новые фичи в старом пуле, они реализованы в новом пуле (в нём будут создаваться виртуальные машины).- Справка: pool (пул) — группа серверов, имеющая единый административный центр (мастера пула), имеющих единую конфигурацию и общие хранилища. В контексте нашего облака означает высшую иерархическую единицу сегментации облака. Пулы не взаимодействуют между собой, хотя и подчиняются единому серверу API.
Мы будем продолжать поддерживать старый пул длительное время (не обещаю, что «всегда», но весьма долго — точно), а все новые машины будут создаваться в новом пуле — именно там будут работать снапшоты, «нативные ядра» и именно там находятся новые шаблоны.
