Наверх ▲

Erlang для высоконагруженных систем

Валентин Нечаев Валентин Нечаев Ведущий инженер по разработке программного обеспечения в компании «Massive Solutions Ltd».

Валентин Нечаев: Добрый день всем присутствующим! Меня зовут Валентин Нечаев. Я руководитель группы разработки мониторинга управления в компании Massive Solutions. Мой доклад посвящен проблемам мониторинга современных вычислительных кластеров и реализациям проблем.

Немного предыстории

С чего вообще начиналась эра компьютеров на этой планете? Почему мы, собственно, называем их компьютерами, а не вычислительными машинами? Изначальной целью создания компьютеров было вычисление. Потом их начали использовать для других целей (в качестве телефона или еще чего-то). Да, в некоторых языках это отразилось. Французы говорят (извините за мое произношение) что-то типа “ordinateur”, то есть управленец, организатор. Тем не менее, для нас компьютеры – это вычислительные машины.

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

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

Кластер «Ломоносов»

Приведу пример с политическим оттенком. Кто помнит кластер в МГУ под названием «Ломоносов»? Как только он был создан и начал более-менее нормально работать, дал первый результат, приехал президент Медведев и  торжественно разрезал ленточку. Но в политику мы углубляться не будем, у нас здесь тематика техническая.

Чем «Ломоносов» был интересен? Почему он стал прорывом для фирмы, которая его построила («Т-Платформы»)? Они занимались аппаратным обеспечиванием. Для нас, организовывавших мониторинг кластера, внове было колоссальное количество задач, которые до того или вообще не ставились, или решались частично, или в принципе не могли быть решены, потому что чего-то не хватало. 

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

Посмотрим на такой же показатель для среднего вычислительного кластера нескольких последних лет – будет 10-20 киловатт на стойку. Это уже серьезно. Если взять кластер «Ломоносов», там 70 кВт. Посмотрим на ближайшие планы (этого ожидает следующее поколение) – 200 кВт. Даже 70 кВт – это уже много. Представьте себе ситуацию, когда дом забит радиаторами, а батареи вовремя не включили. Можете себе представить, сколько это мощности? Что получится, если, например, ее вовремя не отводить?

 

Это, к счастью, кадр не с нашей установки. Могу похвастаться тем, что на ряде подконтрольных нам объектов подобные ситуации были предотвращены. Но в случае тех же 70-ти киловатт на стойку, как у «Ломоносова», время критической реакции до того, как аппаратура перегреется, составляет где-то 40 секунд. Может быть, она будет делать вид, что работает, но ее нужно снимать с "боевой" работы и полностью тестировать заново. При прогнозах, скажем, на 200 киловатт время сокращается до 10 или даже 5 секунд.

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

Хорошо, поставим специального человека. Но следующий этап – это 200 киловатт. Человек не успеет никуда добежать, прежде чем все начнет в переносном смысле плавиться и стекать на пол.

Будем реагировать, скажем, по аппаратуре. Мы убедились, что большую часть аппаратуры, которая реально применяется, нельзя опрашивать по SNMP, как принято опрашивать большинство средств инфраструктуры. Все эти УПС, чиллеры, "воздуходуйки", - как бы конкретное устройство ни называлось. Нельзя опрашивать чаще, чем раз в 4 секунды. Где-то так в среднем, потому что иначе они просто не справляются. Да, SNMP затратный. Да, на процессорах для него экономят. Или не экономят, а заранее ставят такие, чтобы тоже не перегревались. Но это, извините, не работа.

Вывод

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

К чему приходим?

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

Кстати, TCP практически не работает. Мы не надеемся на его так называемые "гарантии". Это уже не то. Пусть оборудование все посылает по UDP. Если где-то будет провал, то он будет. В идеале, кстати, надо использовать STTP. Но пока что этот протокол нормально реализован только в BSD-системах. В Windows есть какие-то намеки на стек, а в Linux слабоватая реализация. Больше, его вообще нигде нет. Хотя с момента принятия стандарта прошло уже 11 лет. 

Собираем данные, обрабатываем, группируем. Групповая логика. Проблема по уровню узла в целом. Есть, например, 12 датчиков температуры ядер. Два процессора по 6 ядер, у каждого ядра свой датчик. Нужно все это собрать, проанализировать. Узлу "плохо". Шасси в целом близко к перегреву. Сразу же включается система аварийного отключения по этим данным. Даже если не будет аварийного отключения, начнется какой-то сбор данных - может, тут элементарно дверь в шкаф не закрыли? Может, кто-то картонку положил? 

Отсюда выводится то, что я обозначил как «суммарное состояние». 

Суммарное состояние

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

Дальше. Система должна обеспечивать как минимум автоматический самоконтроль. Если что-то в ней не так, она должна уметь "жаловаться", насколько она это опознает. 

Нужно еще обеспечение честного ручного контроля. Те, кто помнит старую радиоаппаратуру, помнят, что практически на любом устройстве с кучей лампочек была такая кнопка с названием "control lamp". Нажимаешь – все загораются. Если не загораются – перегорел, срочно менять, потому что устройство уже не в счет. 

Точно так же и с ручным контролем. Например, мы подали на вход 2, все должно по длинной цепочке пойти и выдать, например, 2 умножить на 7. Проверяем на выходе – 14, но не 2. Или 4, если там такая логика. Десятку "обрезали".

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

Эффективность использования аппаратуры

Это "всплыло" не сразу, но оказалось по последствиям чуть ли не серьезнее проблем с оборудованием. Это эффективность использования аппаратуры. Представьте себе: установлен кластер, грубо говоря, за 50 миллионов долларов, и тут оказывается, что запущенная на нем задача работает в десятки раз медленнее, чем нужно. Почему? Потому что, например, задача неоптимально работает с памятью: процессор постоянно "спит" в промахах кэша (англ. cache miss). Или она неоптимально работает с распределенной файловой системой. 

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

Для задач из области классической математики, которые сводятся к умножению матрицы размером десятки миллионов на десятки миллионов, типичный шаблон выполнения какой. Подсчитали свой локальный кусочек, затратили на это микросекунду. "Сказали" поменяться с соседями. Кстати, использовать Ethernet уже не получится. Нужен InfiniBand с гарантированным временем реакции 2 или 3 микросекунды в зависимости от настройки, за это время данные уже перейдут через RDM SCSI.

Пришли данные. 3 микросекунды ждем, 2 микросекунды считаем, 3 микросекунды ждем – что за эффективность? Фактически задача постоянно простаивает. А это надо еще синхронизировать на уровне единого барьера по всем узлам, исполняющим задачу... 

Как же такое мониторить?

Сейчас есть так называемый проект HOPSA (Holistic Performance System Analysis), начатый несколькими суперкомпьютерными центрами России, Европы и несколькими европейскими университетами. Входной объем данных, который они хотят, просто чудовищен. 

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

Как осуществляется управление всем этим?

Практически вся управляющая часть, особенно верхние слои, реализована у нас на Erlang+OTP. Вы уже слышали  выступления Максима Лапшина, Роберта Вирдинга. Вы уже поняли, что Erlang – штука весьма полезная.

О мониторинге задач я уже рассказал.

Почему мы выбрали Erlang+OTP?

Благодаря каким факторам решение Erlang+OTP оказалось фактически единственным подходящим под наши изначальные условия?

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

Возьмем "Си". Если у вас не тот указатель, то вы запортите чужие данные, и все пойдет вразнос. Непонятно, как такое отслеживать. Да, там есть какие-то средства, но они обеспечивают только частичную безопасность.

Java. Да, по случайному указателю вы данные не запортите. Но на логике можно влезть в чужие данные. Все взаимодействия между процессами Erlang должны производиться явно. Если вы хотите разделяемое состояние, оно должно быть явно описано соответствующими средствами. Вы используете разделяемое состояние. Да, вы можете сымитировать глобальные переменные, вы даже можете сымитировать мьютексы с условной переменной (англ. condition variable). Пожалуйста, сколько угодно. Но это будет медленно. Вы все делаете явно.

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

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

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

Наконец, есть возможность обновления без остановки. У вас есть какой-то код. Вы загрузили новую версию модуля, она начала исполняться. Если вам так важно произвести какое-то обновление (например, это новые версии и другие внутренние структуры), значит, там процедура чуть более сложная, но она автоматизируется стандартными средствами. 

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

Где еще эти факторы более или менее сочетаются?

Помимо той же прозрачности взаимодействия, мы посматривали на возможность реализации на Python. Но там нет таких "дешевых" процессов на уровне среды исполнения. Лучший мультипроцессинг, который у него есть в версии 2.6, это фактически системные процессы, соответственно, более тяжелые. Обновление кода "на ходу" без перезагрузки есть, но оно требует значительно более хитрых "костылей". Да, реализуемо. "Костыли" есть в поисковиках на первой же странице. Но это "костыли", они не дают аккуратности. Про прозрачность вообще не говорю.

Каковы отрицательные стороны выбора Erlang?

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

Последний вопрос – адаптация программистов. Проблема тут только психологическая. Многие боятся функционально-декларативного программирования, как огня. Не знаю, может, кому-то лень, может, у кого-то с ADC проблемы. Но есть сотрудники, которые в принципе Erlang не приемлют. Что делать – разводим руками. 

Например, когда мы сманили, так сказать, "группу военных сисадминов", посадили их программировать на Erlang и получили весьма неплохие результаты, это был чуть ли не уникальный результат. Я так поначалу думал. Но пару месяцев назад приехал Лев Валкин и рассказал аналогичную историю. Сегодня Максим Лапшин рассказывает то же самое. Берем людей неважно откуда, сажаем их за компьютеры. Они первый раз Erlang увидели – через два дня уже результаты. Как говорится в известном мультике: «Это «ж-ж-ж» неспроста». Что-то хорошее в этом есть.

 

Вернемся к нашей системе. Вот множество букв и цифр. Что это такое? Как уже говорил: построение, которое требует восстановления из любой ситуации. В частности, представим себе приложение, у которого есть внутреннее состояние текущей картины наблюдаемых объектов. Оно "упало", зарабало – картины нет. Она должна откуда-то возникнуть. 

Какой отсюда вывод?

Все сообщения, входящие к нему, должны регулярно повторяться в зависимости от их важности. Как у нас задано в одном из стандартных наборов настроек, уровень "critical" – 30 секунд повтора, уровень "danger" – 90 секунд, уровень "warning" – 5 минут.

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

Ответ давно известен: нужна шина. Есть отправители, есть подписчики. Но на шину поступает все без исключения. Шина должна быть, в принципе, одна. Она должна справляться с тем, что здесь сообщения такие, здесь такие, здесь должна быть такая-то выборка, здесь такая-то. Все это надо достаточно эффективно выбирать.

В качестве примера несколько таких сообщений. Кто не знает Erlang, ориентируйтесь на скобки, группировки, – по ним и так логика понятна. Разными цветами я выделил разные поля для фильтрации, которые одновременно надо учитывать. Например, нужно выбирать с такой-то плоскости с уровнем не ниже такого-то события такой-то категории. При этом адрес объекта должен находиться в пределах от и до. Или по части каких-то этих условий.

Зеленое – это плоскость, голубое – первый уровень, потом вид проблемы, потом адрес объекта.

Какие параметры должны быть у шины?

Возьмем объемы, на которые мы рассчитывали при написании первых версий своей системы. 25 тысяч узлов в мониторинге. Выключается генеральная "воздуходуйка" – всем становится "жарко". Узел – это два процессора по 6 ядер. Через несколько секунд они начинают сообщать, что им "жарко". 25 тысяч умножить на 12 – это 300 тысяч. Столько первичных сообщений. Есть еще вторичные – это сообщения об аварийной ситуации, а не просто сообщения. Есть еще групповые сообщения, и так далее. В итоге получается, что мы должны рассчитывать на миллион сообщений в секунду.

А надо еще наблюдать, что происходит с вычислительными задачами. Цифра получилась такая, что на следующую очередь у нас запланировано (не знаю, может быть, это фантастика, но мы к этому стремимся) обрабатывать 100 миллионов сообщений в секунду. Да, она будет несколько распределенной, не на одном узле.

Ко всему этому, разумеется, нужна эффективная фильтрация. Тому, кто это не заказывал, по возможности не должно поступать больших потоков ненужных данных.

Смотрели на разные реализации, думалт, что можно применить в качестве такого транспорта. Сначала начали смотреть на реализации на AMQP. Это тот же RabbitMQ, по которому тут была пара докладов. Но он больше сгодится для других условий. Там есть хорошая маршрутизация и много других преимуществ. Но не те масштабы, нашу задачу он не потянет. Расхождение минимум на порядок.

Посмотрели на ZeroMQ. Уже по названию решения ясно, что оно где-то ближе, поскольку дизайн минималистичен, функционал на самом минимуме. Чего не хватало? Не хватало одной простой вещи – более разумной фильтрации, поскольку там она построена по следующему принципу: есть сообщение как поток байтов, его начальная часть должна совпадать. Несерьезно. 

Единственный вариант, который удовлетворил нас в начальной реализации, такой:

Все как в старом добром определении IP по сети. Маска и то, с чем должно совпадать после сравнения с маской. В качестве примера. Само сообщение будет передаваться как внешний двоичный формат (англ. external binary format) Erlang. Все сообщения реальные, я попросил кусочек лога с шины «Ломоносова» и взял несколько примеров. Первое слово (64-битное) – это общее свойство сообщения. Что это аварийное сообщение, что это вторая плоскость, что это отмена, что такой-то датчик и прочее. Второе – адрес, к которому относится.

Erlang-приложение формирует критерии подписки в своем формате. Можете увидеть их внизу. Это формат, в котором указано, по чему именно проверять. Видите, например: тип, какой ловим, – аварийное сообщение (англ. alarm), плоскость – вторая, уровень – не меньше, чем предупреждение (англ. warning). Потом это транслируется в набор значений и маски. Это уже идет в агент шины сообщений, который представлен на данном узле. 

К чему он вообще относится?

На слайде узел мониторинговой фермы. Есть компонент, который называется Clustrx СBios. Фактически это гипервизор. Да, это наш специфический гипервизор под наши задачи. Возможности стандартных нас не устраивали. Может быть, дальше с чем-то скрестим его.

Есть агент. С ним идет общение клиентов. Общение идет через драйвер в ядре, который представлен в виде устройства. Сейчас мы знаем, что есть MSG bus, мы его открываем, можем ему посылать сообщения, принимать сообщения, отправлять подпиской через ECTL.

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

Что мы используем поверх IP-транспорта?

Пока что основная ориентация, к сожалению, на TCP. Как только SCTP будет доработан, перейдем на него. Почему? Потому что TCP парализуется задержками. В наших ситуациях самое "свежее" принципиально важнее того, что уже "несвежее". Пусть оно теряется, пусть оно доходит с опозданием. Должно доходить самое "свежее". 

На TCP сейчас достигнут рубеж. Был эксперимент на 800 тысяч сообщений в секунду, но я ему не совсем верю. 600 тысяч – это уже реальная цифра. На InfiniBand получаем 1 миллион сообщений в секунду. Вопрос вне InfiniBand. 200 долларов на каждый физический узел (как минимум, это дешевый вариант адаптера), и я не скажу сколько на коммутатор. На следующий уровень мы уже можем выйти только фильтрацией в самом сетевом адаптере.

Как этот транспорт дальше применяется?

Сейчас он предполагается в качестве отдельного. Нужна явная передача на него, явное получение от него в обход основного. Еще один из вариантов – замена кластерного транспорта в Erlang. Тут есть свои сложности со специфическими для Erlang типами данных – такими, как тот же "process" или "id". Не буду в это глубоко влезать. Но структура его, в принципе, позволяет заменить. Стандартный транспорт его не "вытянет". Между двумя узлами один TCP-канал, по которому что-то идет. Мы пробами парализовали его так, что собственный hardbit на него не успевал проходить. Правда, оно на это и не рассчитывалось. Это как попытаться водрузить 3 тонны песка на велосипед.

Каковы адаптеры такой шины для Erlang и Cи?

Адаптеры для других языков – по необходимости. Пока такой необходимости еще не было. Пока действует общий принцип: все, что можно делать на Erlang, делается на Erlang. Все, что за пределами этого, реализовано на Си (то, что требует особой оптимизации). Clay – на Python, который, например, запускает Erlang-ноды, собирает для них данные и так далее. Таким замечательным образом у нас все работает.

В общем-то, все. Давайте уже к вопросам.

Вопросы и ответы

Вопрос из зала: Я что-то не понял, ваша шина данных – это все-таки отдельный сервер, к которому подключаются подписчики?

Валентин Нечаев: Нет, концентрации на каком-то отдельном сервере не предполагается. Это отдельный слой реализации, причем в своей основе он не зависит от Erlang. 

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

Вопрос из зала: Вам удалось все возможные условия фильтрации уместить в равенство конвенции с маской?

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

Вопрос из зала: Я так понимаю, размер кластера Erlang-нод – порядка десяти нод. Вы говорили, что около десяти нод на мониторинговые узлы?

Валентин Нечаев: Нет, это я говорил пример. Что с того, что по сравнению с "вылизанным" C, на который будет потрачено пара миллионов человеколет, будет 10 серверов вместо одного? Так, практические примеры – у нас сейчас порядка 30-ти нод. Это если "развесить" туда все, включая, например, генерацию графиков, которую мы пока что сделали через RRD. Это самая тяжелая компонента во всем этом. Но это временно. 

Вопрос из зала: Пришлось тюнить виртуальную машину Erlang?

Валентин Нечаев: Как вам сказать... Да, определенный тюнинг есть, но он несущественный. Пока это не на уровне патчей. Пока что все на уровне запуска с определенными ключами. К примеру, мы сейчас это запустим, разрешим, грубо говоря, использовать 4 потока. Соответственно, все "садится" на 4 ядра, а это 2. Или наоборот, этой 3, этой 3. Может оказывать влияние на производительность слабопредсказуемым образом. Это все нужно тестировать вживую. 

Какой-то тюнинг такого рода есть. Глубоко залезать в виртуальную машину мы не стали… Я не буду рассказывать: «Сейчас мы реализуем разделенный, сейчас гибридный, а сейчас объединенный». Все это не делали пока что. Хотя есть пример того, что будет использовано в ближайшее время. Это полусловный эмулятор. У нас вся среда исполнения 64-битная. Полусловный эмулятор делает так: у одного процесса только 4 гигабайта, но при этом используется 32-битная среда. Ускорение от полутора до трех раз в зависимости от задачи. Его дошлифуют, и мы сразу на него перейдем.

Вопрос из зала: Вы используете Hipe?

Валентин Нечаев: Да, используем. Но сейчас проблема Hipe в том, что он компилируется еще и на определенное количество ядер. Скомпилированное на двух ядрах нельзя запускать на четырех. Он после такого запуска скажет: «Извините, мне ваш нативный код не годится, я пошел дальше все из виртуальной машины сам исполнять». Для финального варианта "вылизывания" буквально последних процентов – тогда Hipe.

Вопрос из зала: Расскажите про свой гипевизор, чем он отличаесят от прочих?

Валентин Нечаев: Про гипервизор... Если сравнивать с другими... Где-то два года назад в ядре Linux произошла грандиозная реформа против всех попыток "впихивания". Кто-то VSAT пытался "впихнуть", кто-то Xen, кто-то еще что-то. Торвальд сказал: «Извините, нам это все не надо, мы сами с усами, мы сами все сможем сделать». 

Появилась штука под названием LXC. Да, она пока что относительно примитивная. Да, у нее не хватает некоторых вещей. Например, тот же Open VSAT позволяет давать гарантированные полосы ресурсов (типа того же процессора или ввода-вывода) отдельным виртуальным машинам. LXC может давать только ограничение сверху в процентах. Тем не менее, LXC позволяет следующее: на том же ядре кое-что запускается хорошо изолированной виртуальной машиной. Мы нацелены на это. 

В то же время и Xen, и VMware, и многие другие хотят использовать так называемые KVM, когда происходит полная эмуляция машины, включая аппаратуру, стартовый Bios и все такое. По большей части это нам не нужно. Это просто излишние затраты и потеря производительности на ровном месте. Поэтому мы за этими гипервизорами и не гнались. 

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

В нем нет ничего особенного. Просто среда для LXC-контейнеров (по желанию, KVM-контейнеров), некоторые специфические ядерные добавки, типа того же MSG Bus.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Константин Осипов

Константин Осипов

Разработчик и архитектор СУБД Tarantool.

Разработчик Tarantool Константин Осипов и его активный пользователь Александр Календарев сравнили Tarantool с Redis.

Павел Уваров

Павел Уваров

Работает в команде Google SRE в Дублине (Ирландия).

Доклад от Google о принципах и процессах, полезных при создании программных систем.

Бадди Брюэр (Buddy Brewer)

Бадди Брюэр (Buddy Brewer)

Cоучредителm и генеральныq директор компании Log-Normal, Inc.

Бадди Брюэр (Lognormal, Inc) рассказывает о разработке высокопроизводительных систем при масштабировании.