Как стать автором
Обновить
13
0
Артём Александров @Qk4l

User

Вопрос больше чем не подошли мультистэйджинг сборки (а по-факту то что описано — оно и есть)


Не совсем так.
multistage-build — часть процесса сборки образа.
В описанном же в статье методе — image rebase сборки образа как такового нет.
Изменяеются только ссылки на слои в манифесте образа, что и даёт существенный выигрыш.

Спасибо за наброс про action плагины.
Почитал про них, переосмыслил. В арсенале однозначно пригодятся =)
Причин конечно же несколько. Это баги в прошивках и «удобные» утилиты управления, и дополнительная прослойка которая мешает снимать статистику по IO, и доп.затраты…

К слову, для работы с 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')
>> I/O выдается в среднем 75 мб/с. на запись по пику

Пики как и провалу там бывают совершенно не предсказуемые.

Кстати довольно хороший прирост производительности дает вынос OSD журнала в ramfs (только для тестов) или на другой высокопроизводительный диск.
Если планируете внедрять, я бы посоветовал взглянуть на решение, когда журналы вынесены на отдельные шустрые SSD диски.
От случая к случаю. Порой и данные теряются и «помогает» только mkcephfs. =(

Я несколько раз пытался перенести корпоративный фотохостинг на ceph, так как хотелось попробовать на вкус фичу, когда часто запрашиваемые данные начинают отдаваться быстрее, но после пары потерь всего хранилиша эксперементирую теперь только с /dev/zero данными =)
Уже около года слежу за развитием Ceph. Проект то что надо для организации бюджетного кластера виртуальных машин, так как позволяет одним и тем же серверам выступать как в роли серверов виртуализации так и OSD нодов.

Но к сожалению для использования в production система еще очень сыра и нестабильна.
Кроме того обновления (которые благо выходят регулятрно) зачастую ломают весь кластер.
Я вот тоже хотел его взять, только теперь призадумался.
Насколько мне известно в #yandex периодически отключают целые дата центры для тестов аварийных ситуаций. Однозначно правильный подход для больших и важных сервисов!
Смысл в том, что бы на основе netflow генерировать список аккаунтов для блокировки. Можно обращать внимание как на количество DNS запросов, так и на трафик в сторону MX серверов. На основе этих данных разбираться с флудерами (банить, ограничивать, помогать избавиться от ботов).

Более конкретно к сожалению не могу, через час на поезд, да и остальное надо смотреть на конкретных реализациях сети.
Вы netflow собираете? думаю, что да. Так почему бы просто не длочить сразу DNS флудеров? За одно будете держать в разумный пределах количество спам ботов (заблоченные подсетки итд).

А статью надо было назвать «Как блокировать нежелательный DNS трафик».
В статье с громким названием «Производительный рекурсивный DNS сервер» сначала рассказывается, что такое A и MX запись, а потом даются советы как дропать запросы для того что бы «производительный сервер» на упал.

Мне одному кажется, что здесь что то неправильно? =)
У нас наверно задачи сильно разнятся, потому что мне сложно представить массу случаев когда необходимо зеркало. За исключением когда нету сети, но разве такое бывает? =)
Для большого парка машин с ubuntu возможно это имеет смысл, хотя я сомневаюсь, что необходим весь репозиторий на 32Gb.

Для удобного и гибкого обновления, экономии трафика ихмо лучше смотреть в стороны вещей вроде apt-cacher-ng.

Я же в свое время перевел «сервер репозитория» на кэширющий nginx на который теперь ходят как rpm так и deb системы.

А в source.list что то вроде deb debian/ lenny main
Связка android (3G megafon) + Ubuntu — неюзабельна.

Хотя я вообщемто и не рассчитывал на это =)
Весь трафик из «Оверсан-Луны» проходит через сетевое ядро Оверсана, расположенное в дата-центре «Оверсан-Меркурий»


После этого я бы не стал называть Оверсан-Луна вторым датацентром, по мне так это расширение первого.
Для экспериментов с ОС, а Вы как я понимаю именно так и используете свою Ubuntu, рекомендую посмотреть в сторону виртуальных систем с возможностью snapshot. VirtualBox вам подойдет.

Для работы этот «бекап» вообще не юзабельный, да еще и только под Debian like.
Возможно поэтому он и удостоился внимания хабрасообщества.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург и область, Россия
Работает в
Зарегистрирован
Активность