Вопрос больше чем не подошли мультистэйджинг сборки (а по-факту то что описано — оно и есть)
Не совсем так.
multistage-build — часть процесса сборки образа.
В описанном же в статье методе — image rebase сборки образа как такового нет.
Изменяеются только ссылки на слои в манифесте образа, что и даёт существенный выигрыш.
Причин конечно же несколько. Это баги в прошивках и «удобные» утилиты управления, и дополнительная прослойка которая мешает снимать статистику по IO, и доп.затраты…
К слову, для работы с RAID контроллерами мы используем локальный файловый кеш в котором сохраняем выдачу от утилит управления.
Просто для того чтобы не создавать дополнительную нагрузку (некоторые не справляются, дают эффект и даже умирают) и получать данные по дискам из кеша быстрее, чем отдаст утилита RAID(а).
Роли используются для организации плейбуков.
По сути в этом проекте для каждой уникальной группы (с точки зрения замены диска) есть отдельная Ansible роль.
Например процесс замены в раздатчике видео будет описан в роли video-download, а процесс замены системного диска с редеплоем сервера в redeploy.
Кастомных action плагинов нет, не было явной необходимости в них. Но build-in конечно используем.
Напрмер assert через которые прогоням проверки перед возратом нагрузки на диск/сервер или закрытием тикета.
Можно, пожалуйста, вопрос по теме?
Я установил в качестве сезона период в 24 часа. Все работает.
Но при отображении графика за период более 24 часов, он весь помечается весь как FAILURES.
>> I/O выдается в среднем 75 мб/с. на запись по пику
Пики как и провалу там бывают совершенно не предсказуемые.
Кстати довольно хороший прирост производительности дает вынос OSD журнала в ramfs (только для тестов) или на другой высокопроизводительный диск.
Если планируете внедрять, я бы посоветовал взглянуть на решение, когда журналы вынесены на отдельные шустрые SSD диски.
От случая к случаю. Порой и данные теряются и «помогает» только mkcephfs. =(
Я несколько раз пытался перенести корпоративный фотохостинг на ceph, так как хотелось попробовать на вкус фичу, когда часто запрашиваемые данные начинают отдаваться быстрее, но после пары потерь всего хранилиша эксперементирую теперь только с /dev/zero данными =)
Уже около года слежу за развитием Ceph. Проект то что надо для организации бюджетного кластера виртуальных машин, так как позволяет одним и тем же серверам выступать как в роли серверов виртуализации так и OSD нодов.
Но к сожалению для использования в production система еще очень сыра и нестабильна.
Кроме того обновления (которые благо выходят регулятрно) зачастую ломают весь кластер.
Насколько мне известно в #yandex периодически отключают целые дата центры для тестов аварийных ситуаций. Однозначно правильный подход для больших и важных сервисов!
Смысл в том, что бы на основе netflow генерировать список аккаунтов для блокировки. Можно обращать внимание как на количество DNS запросов, так и на трафик в сторону MX серверов. На основе этих данных разбираться с флудерами (банить, ограничивать, помогать избавиться от ботов).
Более конкретно к сожалению не могу, через час на поезд, да и остальное надо смотреть на конкретных реализациях сети.
Вы netflow собираете? думаю, что да. Так почему бы просто не длочить сразу DNS флудеров? За одно будете держать в разумный пределах количество спам ботов (заблоченные подсетки итд).
А статью надо было назвать «Как блокировать нежелательный DNS трафик».
В статье с громким названием «Производительный рекурсивный DNS сервер» сначала рассказывается, что такое A и MX запись, а потом даются советы как дропать запросы для того что бы «производительный сервер» на упал.
Мне одному кажется, что здесь что то неправильно? =)
У нас наверно задачи сильно разнятся, потому что мне сложно представить массу случаев когда необходимо зеркало. За исключением когда нету сети, но разве такое бывает? =)
Для экспериментов с ОС, а Вы как я понимаю именно так и используете свою Ubuntu, рекомендую посмотреть в сторону виртуальных систем с возможностью snapshot. VirtualBox вам подойдет.
Для работы этот «бекап» вообще не юзабельный, да еще и только под Debian like.
Возможно поэтому он и удостоился внимания хабрасообщества.
Не совсем так.
multistage-build — часть процесса сборки образа.
В описанном же в статье методе — image rebase сборки образа как такового нет.
Изменяеются только ссылки на слои в манифесте образа, что и даёт существенный выигрыш.
Почитал про них, переосмыслил. В арсенале однозначно пригодятся =)
К слову, для работы с RAID контроллерами мы используем локальный файловый кеш в котором сохраняем выдачу от утилит управления.
Просто для того чтобы не создавать дополнительную нагрузку (некоторые не справляются, дают эффект и даже умирают) и получать данные по дискам из кеша быстрее, чем отдаст утилита RAID(а).
По сути в этом проекте для каждой уникальной группы (с точки зрения замены диска) есть отдельная Ansible роль.
Например процесс замены в раздатчике видео будет описан в роли video-download, а процесс замены системного диска с редеплоем сервера в redeploy.
Кастомных action плагинов нет, не было явной необходимости в них. Но build-in конечно используем.
Напрмер assert через которые прогоням проверки перед возратом нагрузки на диск/сервер или закрытием тикета.
Я установил в качестве сезона период в 24 часа. Все работает.
Но при отображении графика за период более 24 часов, он весь помечается весь как FAILURES.
Параметры создания базы:
'DS:%s:GAUGE:600:U:U' % param,
'RRA:AVERAGE:0.10:1:4464',
'RRA:AVERAGE:0.10:3:4464',
'RRA:AVERAGE:0.10:6:4464',
'RRA:AVERAGE:0.10:12:4464',
'RRA:HWPREDICT:4464:0.1:0.0035:144',
'RRA:FAILURES:4464:2:3:4')
Пики как и провалу там бывают совершенно не предсказуемые.
Кстати довольно хороший прирост производительности дает вынос OSD журнала в ramfs (только для тестов) или на другой высокопроизводительный диск.
Если планируете внедрять, я бы посоветовал взглянуть на решение, когда журналы вынесены на отдельные шустрые SSD диски.
Я несколько раз пытался перенести корпоративный фотохостинг на ceph, так как хотелось попробовать на вкус фичу, когда часто запрашиваемые данные начинают отдаваться быстрее, но после пары потерь всего хранилиша эксперементирую теперь только с /dev/zero данными =)
Но к сожалению для использования в production система еще очень сыра и нестабильна.
Кроме того обновления (которые благо выходят регулятрно) зачастую ломают весь кластер.
Более конкретно к сожалению не могу, через час на поезд, да и остальное надо смотреть на конкретных реализациях сети.
А статью надо было назвать «Как блокировать нежелательный DNS трафик».
Мне одному кажется, что здесь что то неправильно? =)
Для удобного и гибкого обновления, экономии трафика ихмо лучше смотреть в стороны вещей вроде apt-cacher-ng.
Я же в свое время перевел «сервер репозитория» на кэширющий nginx на который теперь ходят как rpm так и deb системы.
А в source.list что то вроде deb debian/ lenny main
Хотя я вообщемто и не рассчитывал на это =)
После этого я бы не стал называть Оверсан-Луна вторым датацентром, по мне так это расширение первого.
Для работы этот «бекап» вообще не юзабельный, да еще и только под Debian like.
Возможно поэтому он и удостоился внимания хабрасообщества.