Переход с OpenVZ на LXC/LXD
Пятница, 7 июня, 9:23
Бодро делаем новое хостинговое окружение на LXC/LXD в целях замены OpenVZ.
Получается, неожиданно, весьма неплохо и, например, много лучше, чем получилось у Proxmox, но..
Напомню, с OpenVZ мы имеем:
Получается, неожиданно, весьма неплохо и, например, много лучше, чем получилось у Proxmox, но..
Напомню, с OpenVZ мы имеем:
- базирование на Centos и систематическое существенное отставание от современного мира (да, что-то бекпортится, что-то не так критично, но современные шедулеры, zfs, местами многократные ускорения чего-то в новых ядрах линкса, которые сюда никак...). В случае с Virtuozzo 7 мы имеем еще и проблемы стабильности.
- плохая поддержка — как от разработчиков, так и от "community", и коллеги, которые пробовали платную поддержку, говорят что различий нет
- плохое состояние OpenVZ как продукта (в последние года)
- более плохая работа коммерческой версии, чем опенсурсной, с точки зрения конечного потребителя
- местами жесткая заточенность и залоченность на сомнительные (ext4, Virtuozzo Storage), с точки зрения потребителя, технологии
- отличная документация
- отличная (!!!) техническая продуманность фич, которые сделаны
- хорошая и изначальная заточенность под около-хостинговые задачи
- современные ядра, фичи, драйвера и т.д.
- де-факто полностью отсутствующее комьюнити и абсолютно нулевая поддержка — в русскоязычных местах невозможно получить ответ (даже плохой и глупый) ни на один вопрос, в англоязычных местах нестандартные сценарии в целях шаред хостинга вызывают недоумение и непонимание, с тем же конечным результатом
- продуктом, в форме именно продукта, оно не является. Начиная с ~ LXD 2.0 всё неплохо, но это пока все еще просто инструмент, причем сильно не самодостаточный
- возможность использовать ZFS и разные современные штуки, но, пока, недостаточно хорошая интеграция с . Например, мы уже придумали как прокидывать юзер-левел квоты, но вот это все — надо пока самостоятельно. Хотя, казалось бы, проблема общая, массовая, и непонятно почему всё так.
- Документация чуть лучше формальной. Чтобы понять, как сделать что-то, требуются гораздо более фундаментальные знания об администрировании и сетях, прочитать только родную документацию никогда не является достаточным (ну и см. п.3)
- Некоторые очевидные фичи непонятно как получить (==отсуствуют), при этом, кажется, писать свои патчи здесь много сложнее.
- полная непродуманность под около-хостинговые задачи. Как реализовывать многие нестандартные сценарии, которые у нас фактически были, причем частоиспользуемы — загадка.
Доброхосту 15 лет
Понедельник, 13 мая, 19:1Как мы в очередной раз не переехали в постгри
Воскресенье, 12 мая, 19:45
Долго медитировал, не заметил, как появилась Percona 8.
Потом долго читал гугл, преимущественно
https://www.percona.com/resources/technical-presentations/mariadb-103-vs-mysql-80-percona-technical-webinar
и
http://blog.dumper.io/showdown-mysql-8-vs-postgresql-10/
Резюме — в очередной раз отменил переход на постгри.
Основной причиной желания попробовать перейти на MariaDB была их репликация (по состоянию на 1-2-3 года назад), но теперь с мусклем 8 и перконой 8, и учитывая все, что написано про мариядб в пдф — не возникает даже желания пробовать (меня мускульный мастер-мастер полностью устраивал, но мне хотелось более новый синхронный или полусинхронный мультимастер и в какой-то момент с марией это получалось лучше).
Основной причиной хотеть постгри было json и нормальные индексы, но теперь всё это в отличном виде есть в мускле 8 (и многое доработано в перконе 8). Составные индексы занимали непомерно диска в мускле и хранились отдельно по полям в посгри (а потому — занимали в очень много раз меньше места0 — как с этим сейчас — не понятно, но кажется очевидным, что в базах в масштабах нескольких гигабайт, когда у меня терабайты ссд простаивают пустые — это не так чтобы важно.
btw, да, мы тут в очередной раз переписываем биллинг и панель и вообще всё. В этот раз правда не с нуля, а очень итеративно, но будет много классных изменений.
Потом долго читал гугл, преимущественно
https://www.percona.com/resources/technical-presentations/mariadb-103-vs-mysql-80-percona-technical-webinar
и
http://blog.dumper.io/showdown-mysql-8-vs-postgresql-10/
Резюме — в очередной раз отменил переход на постгри.
Основной причиной желания попробовать перейти на MariaDB была их репликация (по состоянию на 1-2-3 года назад), но теперь с мусклем 8 и перконой 8, и учитывая все, что написано про мариядб в пдф — не возникает даже желания пробовать (меня мускульный мастер-мастер полностью устраивал, но мне хотелось более новый синхронный или полусинхронный мультимастер и в какой-то момент с марией это получалось лучше).
Основной причиной хотеть постгри было json и нормальные индексы, но теперь всё это в отличном виде есть в мускле 8 (и многое доработано в перконе 8). Составные индексы занимали непомерно диска в мускле и хранились отдельно по полям в посгри (а потому — занимали в очень много раз меньше места0 — как с этим сейчас — не понятно, но кажется очевидным, что в базах в масштабах нескольких гигабайт, когда у меня терабайты ссд простаивают пустые — это не так чтобы важно.
btw, да, мы тут в очередной раз переписываем биллинг и панель и вообще всё. В этот раз правда не с нуля, а очень итеративно, но будет много классных изменений.
Итоги года
Понедельник, 31 декабря, 20:24
Сабж
- Прекрасная женщина все еще живет со мной
- Заработал денег больше, чем в прошлом году
- Еще больше повысил ARPU
- Перестал работать с Гет-Нэте
- Решил кучу интересных технических проблем в Доброхосте
- Так и не запустил ни один новый проект Доброхоста :(
Электронный документооборот
Пятница, 22 июня, 14:47
Я клиент СКБ Контура и пользуюсь их электронным документооборотом — diadoc.ru.
У меня есть электронная подпись — их же.
Чтобы подключить роуминг мне надо что-то печатать на бумаге, подписывать и сканировать.
21 век...
У меня есть электронная подпись — их же.
Чтобы подключить роуминг мне надо что-то печатать на бумаге, подписывать и сканировать.
21 век...