Мониторинг собственный и опирается в основном на сырые метрики процессов/системных величин/интерфейсов. Хранится статистика в Oracle NoSQL — распределенной KV базе данных.
Хотелось бы дать комментарий и с нашей стороны, от имени Flops.ru.
К сожалению, рекомендательная ссылка на нас в единственном экземпляре вызвала некоторые вопросы об аффилированности между нами и Cloudmouse у ряда клиентов и создала для нас некоторые репутационные издержки.
В ответ на эти вопросы хотим отметить: к Cloudmouse мы отношения не имеем, закрываться не планируем, потерь клиентских данных с момента запуска в феврале 2013 года не было и предпосылок для этого нет.
Как бы странно это ни звучало, об этом посте и рекомендации нас в качестве альтернативы мы узнали постфактум от вновь прибывших клиентов, что в итоге вызвало некоторые неудобства (число желающих получить триал превзошло объем зарезервированных под это ресурсов). Мы эту ситуацию сравнительно быстро на наш взгляд отыграли, к вечеру вчерашнего дня все желающие триальные серверы получили:
Мы сожалеем о событиях, связанных с Cloudmouse и приложим максимум усилий, чтобы обеспечить качественный сервис тем клиентам, которые решили воспользоваться рекомендацией.
Надо также помнить про отпечаток сервера, начиная от списка открытых или закрытых портов и версий сервисов и заканчивая такой экзотикой, как публичный ключ на 22 порту (если вдруг он катается вместе со всем остальным). Также иногда встречается вариант, когда атака бьет по всем адресам в истории по очереди, стараясь найти нужный, поэтому шаги с переездом на предыдущие адреса лучше не предпринимать.
Получился довольно ироничный заголовок. Дело в том, что если взять ElasticSearch и проанализировать подозрительную активность на больших объемах, то почти наверняка попытки взлома этого самого ElasticSearch будут в лидерах :)
Звучит похоже на то что у них одновременно полностью рассыпался консенсус из mon и данные самих мониторов были дополнительно полностью утеряны, я правильно понимаю ситуацию?
Ceph надежен для продакшена (хотя и капризен), дело практически наверняка в кривых руках, особенно принимая во внимание факт, что не было бэкапов на внешнем хранилище.
В первом вопросе у вас заключается сам ответ — да, безусловно, состояние и конфигурация виртуалок остаются. У нас нет противопоставления опенстековскому boot from volume — все машины всегда работают только с rbd. В этом случае нода приравнивается к сгоревшей и машины также перезапускаются.
На ваш взгляд, на какой сегмент этот стандарт рассчитан? Через некоторое время весь крупный свичинг, скорее всего, приведется к OF-DPA, а у DSA гибкость в разы меньше, поэтому нишу для него сложновато представить.
Безусловно, отделить можно, просто он тут на ровном месте и большой. Допустим, однократная процедура бекапа 200гбайт-образа выльется, при скорости блочной миграции ну 200мбайт/с, в 40+ минут только на переезды плюс ну полчаса минимум (в реальности скорее 2-3 часа) на отслаивание образа, даже если не брать его сжатие. Процедура восстановления займет, с учетом спиноффа прямо на бекап-сервере и последующего переезда, минут 20. Теперь ухудшаем ситуацию до двух-трех таких операций в параллель и получаем насыщение на уровне очередности операций, при этом принимая допущение, что бекап-сервер обладает как минимум десятигигабитным интерфейсом, у него хватает на все задачи процессора и нет вероятности появления более срочной и приоритетной операции.
Принимая во внимание тот факт, что вы отстраиваете решение на локальном хранилище, непонятно, зачем использовать блочную миграцию для бекапов вместо операции drive_backup, это втрое уменьшит объем сетевого трафика. Ну из из топорной калькуляции выше видно, что проблемы наступают очень рано, примерно на уровне пары-тройки компьют в расчете на один бекапсервер (бекап раз в 3..7 дней, компьюты содержат ну пусть 2Тб данных каждая).
Для примера «не зацепить» можно взять работающий докер. Проблема оверхеда в том, что он создается в рамках одной ноды и влияет на нее же. LVM миррор и DRBD в современном мире действительно, никто не использует :)
Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого? Да, cow плох, когда он не обеспечивается большой хранилкой, переваривающей операции со снимками без потерь, цеф там будет или нетапп — уже вторично, поэтому его использование в большом продакшене отпадает. Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды.
Да, безусловно, с довольно давних времен консистентный дамп всего в qemu стал делаться быстро для cow образов, но из использования такого блокбекенда вытекает масса явных и неявных проблем при масштабировании одной виртуалки или при масштабировании их группы. Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно, но там доделки на два рубля. Все же мы обсуждаем очень нишевое решение, процент пользователей, которым действительно необходим полный стейт, а фриза фс внутри недостаточно, очень невелик и у них как правило есть возможность раскошелиться на коробочный вариант.
Хорошо, заменяем фриз на отслаивание памяти (не прямым дампом, а мигратоподобным вариантом или его аналогом, как выше) и снимком на хранилище из п.2, получаем тот же простой в районе долей секунды и ту же «абсолютную консистентность». Месседж с моей стороны таков, что попытка сделать указанные вещи на обычных локальных образах, raw или cow, приведет к очень высокому оверхеду из-за необходимости прокачивать большой объем данных в первом случае и потенциальной необходимости отслаивать снимки и также прокачивать много байтов во втором, без отслоения надо либо их ротировать, либо все затормозит. Впрочем, такой подход вполне себе имеет право на жизнь, если время доступности бекапа с момента его создания может сильно варьироваться и не регламентировано жестко (доступность = выкачанность на другую физическую сущность).
В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого.
А какие плюсы этот подход дает? Если продолжать держать информацию о снимках в образе, чтобы получать дифференциальные детачнутые копии, то это будет растить размер блок-бекенда, который еще по замыслу катается между машинами, если снимать каждый раз полный дамп — проще воспользоваться drive-backup или чем-то схожим по смыслу и ничего никуда не мигрировать (похоже вариант 3, если имелось в виду то же). В любом случае, двойная блочная миграция в процессе не выглядит продакшеном :)
Мигрирует блочной миграцией? Вообще описанный вариант про корку из коробки недоступен, хотя его можно сделать минимальными силами, и опять же пока дисковый снимок отклеивается (если в этом есть необходимость), все может тормозить. И зачем в любом случае мигрировать машину для снятия бекапа?
Нюанс в том, что все вариации на эту тему очень небыстрые, для промышленного флоу их использовать сложновато. Плюс корка сейчас на лету без простоя не снимается, что ведет к еще большим потерям :).
Чем больше число PG, тем более гладким получится псевдослучайное распределение данных. С другой стороны, при числе PG более 50..70к в одном пуле начинаются проблемы с производительностью кластера.
В случае обычного коммутатора вам с очень большой вероятностью хватит линуксового balance-xxx. У цефа нет точек, являющихся средоточием пропускной способности, так что половинка от максимальной скорости на пару 5-tuple будет очень хорошо работать, за исключением граничных случаев (один клиент, потребляющий всю пропускную способность кластера).
К сожалению, рекомендательная ссылка на нас в единственном экземпляре вызвала некоторые вопросы об аффилированности между нами и Cloudmouse у ряда клиентов и создала для нас некоторые репутационные издержки.
В ответ на эти вопросы хотим отметить: к Cloudmouse мы отношения не имеем, закрываться не планируем, потерь клиентских данных с момента запуска в феврале 2013 года не было и предпосылок для этого нет.
Как бы странно это ни звучало, об этом посте и рекомендации нас в качестве альтернативы мы узнали постфактум от вновь прибывших клиентов, что в итоге вызвало некоторые неудобства (число желающих получить триал превзошло объем зарезервированных под это ресурсов). Мы эту ситуацию сравнительно быстро на наш взгляд отыграли, к вечеру вчерашнего дня все желающие триальные серверы получили:
Мы сожалеем о событиях, связанных с Cloudmouse и приложим максимум усилий, чтобы обеспечить качественный сервис тем клиентам, которые решили воспользоваться рекомендацией.
Ceph надежен для продакшена (хотя и капризен), дело практически наверняка в кривых руках, особенно принимая во внимание факт, что не было бэкапов на внешнем хранилище.
Принимая во внимание тот факт, что вы отстраиваете решение на локальном хранилище, непонятно, зачем использовать блочную миграцию для бекапов вместо операции drive_backup, это втрое уменьшит объем сетевого трафика. Ну из из топорной калькуляции выше видно, что проблемы наступают очень рано, примерно на уровне пары-тройки компьют в расчете на один бекапсервер (бекап раз в 3..7 дней, компьюты содержат ну пусть 2Тб данных каждая).
имелся в виду вариант без нее, п.2
Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого? Да, cow плох, когда он не обеспечивается большой хранилкой, переваривающей операции со снимками без потерь, цеф там будет или нетапп — уже вторично, поэтому его использование в большом продакшене отпадает. Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды.
В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого.