Но приветствуется, то-есть гос. предприятие либо приветствует, что работать на них будут преступники, либо намеренно провоцируют кандидатов на не законные действия, такая логика? Закон закону рознь, под определенные законы можно закрыть почти любого, было бы желание, так что к нарушителям закона отношусь с здравым смыслом, например если кого-то закрыли за просмотр аниме, то виноват не «преступник», а сволочь из чиновников, кто этот закон протащил и поддержал, еще защита чувств не думающих и прочее мракобесие, я не считаю что нарушители этих законов должны нести наказание, а считаю что наказывать надо тех, кто их принимает, в идеале принудительным лечением в психиатрическом отделении.
Опыт работы «black-hat» — как должен был быть санкционирован в прошлом? Или находим кандидата, угрожаем ему статьями и он соглашается работать за минимальный оклад, чтоб не сидеть?
На сколько я понял из описания, то в таблицах истории удалили history_text.id и history_log.id, но не пойму каким образом это может повлиять на партицирование?
Пользуясь случаем, хочу спросить, как можно поставить таймаут для SNMP запросов более 30 секунд, дело в том, что при использовании LLD на БРАС, у которых десятки тысяч интерфейсов, SNMP не успевает опросить их все, хотя по фильтру используется на мониторинге менее десятка (остальные не будут добавлены, но все равно опрашиваются при LLD), можно ли поднять этот таймаут чтоб не получать ошибку из-за закончившегося времени на запрос, либо добавить какую-то проверку, что если данные приходят, а не подвисли, то ждать окончания передачи.
У меня примерно такое-же мнение о Docker, его среда — это DevOps и тесты, для продакшина при его использовании мы кладем болт на безопасность, кроме чужих образов, даже на своих, если в базовой ветке найдена критичная уязвимость, то мы должны обновить все контейнеры, причем многие пересобрать вручную, особенно это критично для тех, где использовали коммит, а не делали докерфаил от базового. Хотя сам я докером иногда пользуюсь, но в основном если надо развернуть быстро какой-то говнософт, который тянет хренову гору зависимостей, но нужен на 1 раз, чтоб не захламлять систему, поставил, раз запустил, что нужно получил и убил.
Хорошо, если это реально так, про стартовые скрипты, а вариант от прошлой версии не катит, если создать в папке с конфигами скрипт с именем контейнера.mount? Про бэкапы я так понял это официальная позиция проекта, хотите бэкапы — покупайте virtuozzo, иначе prlcrl backup не пашет.
Не работал с этой системой, надо глянуть если реально умеет, если не затруднит дайте ссылку на техдоку, а то открыл сайт, а там один рекламный булщит. А какие сложности с OVZ, если мы говорим про предыдущее поколение, а не урезанную седьмую версию?
Docker — не изменяемые контейнеры отдельных приложений.
OVZ/LXC — изменяемые контейнеры полноценной среды.
Что я не смогу сделать на Docker и смогу на OpenVZ
Вопрос не в возможности или невозможности, а в количестве костылей для развертывания, например на OVZ достаточно сложно сделать несколько десятков идентичных, не сохраняющих изменения контейнеров для разных версий определенной программы, попробуйте развернуть на OVZ для одного домена поддержку скажем php 5.2,5.3,5.6,7.0,7.1 чтоб они не конфликтовали между собой и каждый обрабатывал свою часть сайта либо можно было переключаться между ними, а еще разные версии перла, скомпилированного с разными либами и так далее. В свою очередь попробуйте на докере сделать полностью рабочую среду проекта из сотни компонентов, которым надо сохранять все изменения, иметь внутри контейнера несколько СУБД и бэкапиться одним куском, чтоб можно было восстановить на определенный момент всю систему, а не отдельные ее части, разные инструменты для совершенно разных задач.
Неудобным например можно считать в том что OpenVZ 7 убил совместимость с предыдущей версией.
Ну они типа выложили скрипт миграции https://src.openvz.org/projects/OVZL/repos/ovztransfer/browse работает он правда коряво и требует ручного вмешательства во многие контейнеры после миграции, особенно если нет базового темплейта для ОС этого контейнера, но он есть, не скажу что мигратор на LXC работает значительно лучше, да и сам LXC в ProxMox то еще глючное поделие с набором косяков, смотрите заметку, чтоб не повторяться.
Сравнение с Docker не корректно — это абсолютно разные типы контейнеров с разными кейсами использования, то что удобно делать в докер, не удобно в ОВЗ и наоборот. LXC — достаточно молодой продукт с рядом шероховатостей, но потихоньку набирает обороты, если догонит OpenVZ прошлого поколения по стабильности — будет очень круто, но пока еще не догнал.
Интересно ваше мнение об OpenVZ 7.0 в общем, я вот пытался на него перейти с предыдущей версии и у меня стойкое впечатление, что слияние с Virtuozzo просто убило проект, из проекта выкинуты многие удобные вещи, которые были ранее, те же маунты и бэкапы, без которых использование за пределами песочницы для OpenVZ 7 стало сомнительным и все как-бы намекает, вы тут используете демо версию Virtuozzo, не вздумайте применять проект для продакшина.
Если мы раздаем контейнеры всему миру, аля VDS, то нас это парит, если мы используем только внутри своей инфраструктуры где безопасность обеспечивается на уровне самого гипервизора плюс отдельная защита периметра, то нет особой разницы КВМ или ОВЗ, главное удобство админства, тут контейнерам нет равных. Виртуалки тоже используем, но тут есть где развернуться, в принципе возможности сферы покрывают все необходимые задачи и в КВМ просто нет нужды, хотя на других проектах использовал и КВМ с виртио дровами вполне неплохая производительность.
Бэкапы есть только в платной версии — это самое критичное, остальное скорее придирки, управление кластером есть только в платной версии и то в стадии разработки, система миграции из старого в новый OVZ можно считать не работает, она есть но я в качестве теста пытался перенести с 10 контейнеров, 9 не переехали корректно и требовали ручной допилки, живая миграция только для платного их же стораджа. Вообще сравнение есть тут https://openvz.org/Comparison
Так и делаем, OVZ по стабильности очень хорошо допиленный продукт, пока использование новых ОС стоит не очень остро — будем сидеть на нем, там где требуются новые версии ОС, пока будем виртуалить на сфере и ждать когда один из вариантов контейнеризации ОС на современных ядрах будет более-менее стабилен. OVZ 7 тоже в принципе не плох, в плане скорости работы очень понравился, но вот насильное впихивание в него кусков от коммерческого продукта не пошло на пользу проекту, т.к. теперь это не самостоятельный продукт, а демо-версия virtuozzo, которая не годится для продакшина. На докер и производные пытались перейти несколько раз уже, но никак идеология один процесс — один контейнер не ложится на нашу структуру.
KVM дает лишний оверхед, в плане виртуалок вариантов море, у нас есть кластер на сфере и вся виртуализация там, тут именно контейнеры нужны, вот и ждем стабилизации, попутно подбирая другие варианты, может что подойдет.
С радостью бы, но ProxMox 3 уже не поддерживается и имеет тот же OVZ c ядром 2.6, казалось бы выбор Proxmox 4, который перешел на LXC, но тут загвозтка в стабильности, которой просто нет, мы пару недель гоняли его на тестовом кластере — это просто ужасно, без преувеличений, на данный момент он не готов для продакшина, может и допилят через пару лет, но пока вот так https://habrahabr.ru/post/278877/ итого пока выбор выглядит очень не радостно: Proxmox 4 — не стабилен, OVZ 7 — не достаточно базовых возможностей, урезано много основного, чтоб подстегнуть к покупке Virtuozzo 7, который распространяется по подписке с платой за каждый контейнер и сам по себе дорогой, тестовый кластер на всего 3 ноды и 20 контейнеров нам посчитали в 540$ в месяц, причем на данный момент это только зарелизившийся продукт без комьюнити. Да еще есть LXD — на данный момент не умеет живую миграцию, но вроди как обещают скоро допилить, может что упустил, но вся контейниризация уходит в сторону докера, вот и испытываю муки выбора, просматривая все более-менее похожее с попыткой хотя-бы мысленно адаптировать под мои задачи.
Потому что это все и еще куча различных систем ща живет в кластере на OpenVZ с ядром 2.6 который и прекрасно работает, в смысле выпадение любой из нод не сказывается на жизни системы, в качестве ФС — Ceph. Но есть такая неприятность, что новые версии ОС не поддерживаются в OpenVZ прошлого поколения, а вот с OpenVZ 7 есть ряд косяков, они перешли на prlctl вместо vzctl, который кусок кода virtuozzo и большая часть необходимого функционала теперь не доступна, хотите функционал — купите virtuozzo (ценообразование там либо под откаты либо просто не вменяемо дорого), иначе в системе нет даже банальных бэкапов. Вот и стоим перед проблемой, на что нам мигрировать пол сотни контейнеров в OVZ, если считать в докерах, то будет пару тысяч процессов, причем не очешуеть обслуживать все это и поддерживать. Для девопса — выбор докера очевиден, а вот для продакшина предпочтительней полноценные контейнеры с ОС внутри и сохранением состояния, пока что в поиске.
Из живого примера что пришло на ум. Биллинг ISP:
1) Демона самой биллинг системы
2) Mysql база данных
3) Redis база данных
4) Nginx+HHVM
5) Radius сервер
6) Около 10 демонов шлюзов для взаимодействия с платежными терминалами типа киви.
7) ERP интегрированная с ядром биллинга, в ней же тикетсистема с собственной базой, десятком демонов (связь с телефонией, 1С и т.п.) при этом обновления для ERP части выходят примерно раз в неделю.
Коротче штук 30 процессов которые логично держать в рамках единого контейнера и бэкапить целиком, а не по частям, для воссоздания образа всей системы на определенный момент времени в случаи краха. В докер в теории можно все это засунуть, сторадж под mysql, сторадж под редис, стораджу для логов работы скриптов и радиуса, остальное каждый процесс в свой контейнер, но поддерживать это все и восстановить на определенный момент времени — это будет ад.
По поводу эпизодической нагрузки, есть контейнеры выполняющие например суточный, месячный годовой рассчеты бухгалтерии, соответственно суточный грузит систему около 40 минут в сутки, остальное время почти не нагружает, месячный около 7 часов в месяц и так далее, то-есть ресурсы нужны эпизодически, но сразу много, разделить на несколько процессов это не выйдет, так как единый процесс производит рассчеты и генерацию отчетов. Для того же OVZ это не проблема, он может динамически управлять ресурсами в процентном соотношении от доступных, что намного удобней и логичней чем статическая привязка к определенным параметрам, коротче задачи не девопс, по этому докер — как сову на глобус местами натягивать, можно, но усложняет обслуживание вместо упрощения.
Интересный вариант, надо попробовать на стенде погонять по стабильности, а то ценовая политика Virtuozzo 7 меня крайне огорчает, так что с OpenVZ придется куда-то уходить, вот ищу вариант куда с наименьшим геморроем в плане миграции.
Спасибо за развернутый ответ, пара неясностей осталась.
>>Если вы сразу выделите 3 слейва — то сервисы разойдуться по них достаточно равномерно.
Вопрос не как они расходятся при запуске, с этим обычно нет проблем ни у одной кластерной системы, но представим ситуацию мы запустили много процессов, они успешно разошлись по нодам, но в какой-то момент часть из них успешно завершилась и возникает ситуация, что одна нода загружена в полку, а остальные простаивают, вот для такой ситуации живая миграция очень необходима.
>>Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
То, есть нельзя указать опционально, что процессы должны запускаться всегда и при любой загрузке, но в случае отсутствия свободных ресурсов, занятые ресурсы перераспределяются пропорционально указанным в них настройкам. То-есть если одному процессу мы дали в настройках 4 ядра и 12 гиг памяти а второму дали 2 ядра и 4 гига, а у нас есть скажем всего 4 ядра и 8 гиг, то процессы все равно должны запуститься оба, но первый возьмет 3 ядра и 6 гигов, а второй оставшиеся? Часто некоторые процессы требуют много ресурсов очень эпизодически в остальное время они им не нужны и нет смысла их жестко бронировать за процессом.
>> Докер как раз чудесно ложится в парадигму микросервисов и Месоса
Не всегда, иногда микросервис требует более полного воссоздания окружения, когда в один контейнер мы запихиваем несколько процессов вместе с их взаимосвязью, плюс имеем изменяемую ФС (не все сервисы умеют писать все свои изменения в БД) на время работы контейнера, так как нам нужно чтоб он сохранял свое состояние после перезапуска, бывает что возможностей докера без костылей для этого не хватает, а тот-же OVZ или LXC прекрасно с этим справляются.
Интересный продукт, если знаете пара вопросов:
1) Что происходит с запущенными процессами при внезапной смерти slave ноды? Процессы перезапустятся на других нодах?
2) Есть ли живая миграция процессов между нодами, скажем нода один сильно загружена а ноды 2 и 3 простаивают, переедут ли процессы автоматом с более нагруженной ноды на менее нагруженную или хотя-бы ручная миграция?
3) Есть ли поддержка механизма fencing/stonith, если например одна из нод, мастер или слейв перезапустилась и после перезапуска работает криво и мешает работе всего кластера, произойдет ли ее принудительно отключение от кластера?
4) Есть ли поддержка изменяемых контейнеров (OpenVZ/LXC), а не только Docker, если да то как обеспечивается сохранность внутренних процессов и данных при крахе ноды, есть лик акая-либо кластерная FS в основе?
5) Сроден предыдущему, для баз данных как-то обеспечивается сохранность данных при выходе из строя одного из узлов? Если мы запустим несколько баз в режиме собственной репликации, можно ли их привязать к конкретным нодам, чтоб запускались только на них?
Пользуясь случаем, хочу спросить, как можно поставить таймаут для SNMP запросов более 30 секунд, дело в том, что при использовании LLD на БРАС, у которых десятки тысяч интерфейсов, SNMP не успевает опросить их все, хотя по фильтру используется на мониторинге менее десятка (остальные не будут добавлены, но все равно опрашиваются при LLD), можно ли поднять этот таймаут чтоб не получать ошибку из-за закончившегося времени на запрос, либо добавить какую-то проверку, что если данные приходят, а не подвисли, то ждать окончания передачи.
Не работал с этой системой, надо глянуть если реально умеет, если не затруднит дайте ссылку на техдоку, а то открыл сайт, а там один рекламный булщит. А какие сложности с OVZ, если мы говорим про предыдущее поколение, а не урезанную седьмую версию?
Docker — не изменяемые контейнеры отдельных приложений.
OVZ/LXC — изменяемые контейнеры полноценной среды.
Вопрос не в возможности или невозможности, а в количестве костылей для развертывания, например на OVZ достаточно сложно сделать несколько десятков идентичных, не сохраняющих изменения контейнеров для разных версий определенной программы, попробуйте развернуть на OVZ для одного домена поддержку скажем php 5.2,5.3,5.6,7.0,7.1 чтоб они не конфликтовали между собой и каждый обрабатывал свою часть сайта либо можно было переключаться между ними, а еще разные версии перла, скомпилированного с разными либами и так далее. В свою очередь попробуйте на докере сделать полностью рабочую среду проекта из сотни компонентов, которым надо сохранять все изменения, иметь внутри контейнера несколько СУБД и бэкапиться одним куском, чтоб можно было восстановить на определенный момент всю систему, а не отдельные ее части, разные инструменты для совершенно разных задач.
Ну они типа выложили скрипт миграции https://src.openvz.org/projects/OVZL/repos/ovztransfer/browse работает он правда коряво и требует ручного вмешательства во многие контейнеры после миграции, особенно если нет базового темплейта для ОС этого контейнера, но он есть, не скажу что мигратор на LXC работает значительно лучше, да и сам LXC в ProxMox то еще глючное поделие с набором косяков, смотрите заметку, чтоб не повторяться.
С радостью бы, но ProxMox 3 уже не поддерживается и имеет тот же OVZ c ядром 2.6, казалось бы выбор Proxmox 4, который перешел на LXC, но тут загвозтка в стабильности, которой просто нет, мы пару недель гоняли его на тестовом кластере — это просто ужасно, без преувеличений, на данный момент он не готов для продакшина, может и допилят через пару лет, но пока вот так https://habrahabr.ru/post/278877/ итого пока выбор выглядит очень не радостно: Proxmox 4 — не стабилен, OVZ 7 — не достаточно базовых возможностей, урезано много основного, чтоб подстегнуть к покупке Virtuozzo 7, который распространяется по подписке с платой за каждый контейнер и сам по себе дорогой, тестовый кластер на всего 3 ноды и 20 контейнеров нам посчитали в 540$ в месяц, причем на данный момент это только зарелизившийся продукт без комьюнити. Да еще есть LXD — на данный момент не умеет живую миграцию, но вроди как обещают скоро допилить, может что упустил, но вся контейниризация уходит в сторону докера, вот и испытываю муки выбора, просматривая все более-менее похожее с попыткой хотя-бы мысленно адаптировать под мои задачи.
1) Демона самой биллинг системы
2) Mysql база данных
3) Redis база данных
4) Nginx+HHVM
5) Radius сервер
6) Около 10 демонов шлюзов для взаимодействия с платежными терминалами типа киви.
7) ERP интегрированная с ядром биллинга, в ней же тикетсистема с собственной базой, десятком демонов (связь с телефонией, 1С и т.п.) при этом обновления для ERP части выходят примерно раз в неделю.
Коротче штук 30 процессов которые логично держать в рамках единого контейнера и бэкапить целиком, а не по частям, для воссоздания образа всей системы на определенный момент времени в случаи краха. В докер в теории можно все это засунуть, сторадж под mysql, сторадж под редис, стораджу для логов работы скриптов и радиуса, остальное каждый процесс в свой контейнер, но поддерживать это все и восстановить на определенный момент времени — это будет ад.
По поводу эпизодической нагрузки, есть контейнеры выполняющие например суточный, месячный годовой рассчеты бухгалтерии, соответственно суточный грузит систему около 40 минут в сутки, остальное время почти не нагружает, месячный около 7 часов в месяц и так далее, то-есть ресурсы нужны эпизодически, но сразу много, разделить на несколько процессов это не выйдет, так как единый процесс производит рассчеты и генерацию отчетов. Для того же OVZ это не проблема, он может динамически управлять ресурсами в процентном соотношении от доступных, что намного удобней и логичней чем статическая привязка к определенным параметрам, коротче задачи не девопс, по этому докер — как сову на глобус местами натягивать, можно, но усложняет обслуживание вместо упрощения.
>>Если вы сразу выделите 3 слейва — то сервисы разойдуться по них достаточно равномерно.
Вопрос не как они расходятся при запуске, с этим обычно нет проблем ни у одной кластерной системы, но представим ситуацию мы запустили много процессов, они успешно разошлись по нодам, но в какой-то момент часть из них успешно завершилась и возникает ситуация, что одна нода загружена в полку, а остальные простаивают, вот для такой ситуации живая миграция очень необходима.
>>Иначе, деплой на Марафоне будет висеть в Waiting состоянии.
То, есть нельзя указать опционально, что процессы должны запускаться всегда и при любой загрузке, но в случае отсутствия свободных ресурсов, занятые ресурсы перераспределяются пропорционально указанным в них настройкам. То-есть если одному процессу мы дали в настройках 4 ядра и 12 гиг памяти а второму дали 2 ядра и 4 гига, а у нас есть скажем всего 4 ядра и 8 гиг, то процессы все равно должны запуститься оба, но первый возьмет 3 ядра и 6 гигов, а второй оставшиеся? Часто некоторые процессы требуют много ресурсов очень эпизодически в остальное время они им не нужны и нет смысла их жестко бронировать за процессом.
>> Докер как раз чудесно ложится в парадигму микросервисов и Месоса
Не всегда, иногда микросервис требует более полного воссоздания окружения, когда в один контейнер мы запихиваем несколько процессов вместе с их взаимосвязью, плюс имеем изменяемую ФС (не все сервисы умеют писать все свои изменения в БД) на время работы контейнера, так как нам нужно чтоб он сохранял свое состояние после перезапуска, бывает что возможностей докера без костылей для этого не хватает, а тот-же OVZ или LXC прекрасно с этим справляются.
1) Что происходит с запущенными процессами при внезапной смерти slave ноды? Процессы перезапустятся на других нодах?
2) Есть ли живая миграция процессов между нодами, скажем нода один сильно загружена а ноды 2 и 3 простаивают, переедут ли процессы автоматом с более нагруженной ноды на менее нагруженную или хотя-бы ручная миграция?
3) Есть ли поддержка механизма fencing/stonith, если например одна из нод, мастер или слейв перезапустилась и после перезапуска работает криво и мешает работе всего кластера, произойдет ли ее принудительно отключение от кластера?
4) Есть ли поддержка изменяемых контейнеров (OpenVZ/LXC), а не только Docker, если да то как обеспечивается сохранность внутренних процессов и данных при крахе ноды, есть лик акая-либо кластерная FS в основе?
5) Сроден предыдущему, для баз данных как-то обеспечивается сохранность данных при выходе из строя одного из узлов? Если мы запустим несколько баз в режиме собственной репликации, можно ли их привязать к конкретным нодам, чтоб запускались только на них?