Новая зонированная система хранения данных Clodo

[kronos]

А что такое «обычный облачный хостинг»? Отдельно взятый облачный провайдер, название которого не указывается или что?

[lumenous]

Это наверно Скалакси
=))))))))

[arree]

Это как «обычный стиральный порошок». Никто их не видел, но сравнения хорошие.

[mvs]

Существующие VPS'ы клиентов уже используют данную СХД или она только для новых?

[damad]

Все новые виртуальные машины создаются на новой системе хранения данных. Часть старых клиентов уже также переведена на новую СХД. Постепенно будут переноситься и все остальные клиенты. Если вы — клиент Clodo и хотите перейти на новую систему, просто подайте заявку в техническую поддержку.

[mvs]

Клиент, хочу, подал :-)

[MaXyC]

пошел делать бекапы…

[damad]

Перед перенос мы делаем бэкап сами.

[MaXyC]

верю 100%, но бывают человеческий фактор, да и за последние пол года все равно бекапов нет у меня… *каюсь*

[arree]

50 гигабайт в секунду на запись? Вы уверены?
Также интересно, как быстро будет идти live-миграция между зонами. Диски тоже ведь нужно с зоны на зону мигрировать?
Ну и инфинибэнд-коммутатор как, на каждой зоне свой?

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

[realloc]

50 Гб/с это средняя скорость заполнения кеша через два Infiniband адаптера. Несколько Xen-нод вполне в силах дать такую нагрузку.
Live миграция есть, естественно синхронизация дисков между зонами занимает некоторое время, но происходит достаточно быстро, всё по тому же Infiniband.

Технические подробности скорее всего будут в следующих постах.

[arree]

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

[lohansky]

Линейного, но все равно много.

[arree]

Да, прошу прощения, линейного.

[realloc]

Большой кеш на таргете сделан именно для сдерживания всплесков активности по I/O. Потом он с разумной скоростью скидывается на диски. Опять же вероятность таких всплесков на значительное время достаточно мала.

[arree]

Даже 100Гб вряд ли влезет в кэш, не вытеснив оттуда всё и вся (хотя, конечно, зависит от ваших нод, может там четверть терабайта ОЗУ на каждой… Впрочем, графики говорят об обратном).
Держать образ диска ВМ целиком в кэше (или вообще держать часть только в кэше, пока она скидывается на диск) — это очень опасно, мне кажется. Малейший сбой, и клиент прощается с данными.
Также интересно, как при живой миграции машины между зонами это выглядит с т.з. мигрирующего инстанса. Чтение/запись не проседают, изменения (попадающие в кэш на старой ноде?) корректно дописываются?

Конечно, стоило бы дождаться хоть каких-то технических подробностей, но уж очень интересно.

[realloc]

Live миграция между зонами в жизни VPS не должна происходить часто, только при кардинальной смене поведения на долгое время и только если мешает жить другим. Да, это дорогая и не быстрая операция, статистически такое происходит крайне редко. Скорость I/O при этом падает, но не более 50% в худшем случае.

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

[arree]

Репликацию для того, чтобы в памяти остались кеши? Можете подробнее рассказать?

[lohansky]

А данные как реплицируются на две сторадж ноды?

[sfcr]

«А вот!» ;) (посредством md)

[lohansky]

А чем кэшируете в dom0?

[sfcr]

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

[multagor]

Интересно: насколько утилизируется полоса Infiniband при обращении виртуальных машин к дискам в своей «зоне»? И какая нагрузка на самом ядре Infiniband?

[arree]

Тут ещё интересна архитектура Infiniband. Судя по схеме, в каждой зоне свой коммутатор, но они должны быть как-то связаны между собой и управляющим кластером => ещё один… Не многовато?
Или один коммутатор на всех, но это совсем не «абсолютно независимы».

[lohansky]

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

[feedbee]

Хороший ответ «обычному» облачному хостингу :)

[AlexoLive]

Кому это важно, на новой СХД сейчас доступен всего один автоматический бекап который заменяет ручной.

[realloc]

Подождите немного, будет запущена новая система бэкапов. Как просили пользователи.

[easy_john]

Привет, поздравляю с первым постом. :)
По теме как/чем вы делали кеширование на чтение?
35к иопсов кто получает? отдельная машина, или это общее на стор?
Как с гарантированнными iops на виртуалку?
Кто такой «обычный облачный»? :)
С селектелом производительность дисков сравнивал?

[realloc]

Утро!
Тесты делались на нескольких виртуалках одновременно при средней загруженности стораж зоны с выключенными шейперами. В реальности шейперы будут ограничивать иопсы в зависимости от размера виртуалки. Так что 35к в графиках тестов именно на машину.

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

Про «обычный облачный» легко догадаться.
С Селектелом сравнение можно вывести из других статей на хабре. =)

[easy_john]

А какая связь между размером виртуалки и иопсами?

Да, я там заметил уже, что 35к это на запись, ее всегда проще кешировать, а на чтение там 15к.

Ладно, будем ждать подробностей. И кеширование на чтение очень интересно.

[realloc]

Связь в том, что 5 виртуалок по 5 гб диска должны суммарно получать иопсов столько же, сколько машина с диском на 25Гб, например. Ибо справедливо.

[easy_john]

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

[realloc]

There is no justice there is only me…

Я имел ввиду что в реальности вес для шейпера выставляется относительно объёма потребления ресурсов. Кроме диска есть ещё ряд параметров которые надо учесть и формула выглядит сложнее. Но это уже технические подробности не из этой статьи.

[damad]

Кол-во иопсов напрямую зависит от денег которые клиент тратит на виртуальный сервер. И это справедливо.

[easy_john]

Почему просто не продать иопсы? Если я их массово потребляю — я буду за них платить и не буду впустую покупать ненужное мне место на сторе, и наоборот, если мне надо много места но не нужны иопсы — оплачу только место.

[damad]

Есть такое в планах.