Назад | Перейти на главную страницу

База данных MySQL / Percona Heavy Production в контейнере openvz

Итак, в настоящее время я использую базу данных MySQL 5.1 со следующими характеристиками:

Я планирую перенести свой физический сервер, а также мой сервер mysql на сервер Percona 5.6.

Я использую кластер Proxmox для остальной части моей инфраструктуры, поэтому я хотел бы поместить свой новый сервер MySQL в специальный контейнер openvz (только один на хосте).

Мне уже удалось это настроить, и, похоже, он работает хорошо, однако мне все еще интересно, хорошая ли это идея.

Есть отзывы?

Будьте осторожны при использовании OpenVZ (Proxmox или иначе) для любых операций, где может быть много дискового ввода-вывода. По опыту могу сказать, что это очень, очень медленно - в некоторых случаях примерно вдвое меньше, чем у собственного оборудования. Это особенно плохо с записью, и тем хуже, чем больше контейнеров на сервере, выполняющих чтение и запись (подумал, что последняя часть этого не применима в вашем случае).

Кроме того, имейте в виду, что MySQL очень требователен к ресурсам и может легко либо убить OOM, либо иным образом достичь ограничения контейнера, если вы не установили их должным образом. Опять же, по опыту, это может быть сложно. Также существует тот факт, что некоторые вещи, которые помогают MySQL работать лучше, например, огромные страницы, не могут быть установлены из контейнера, поэтому вы можете в конечном итоге переключаться с хоста на гостя и обратно.

Практически единственное, что вы получите от размещения MySQL в контейнере, - это изоляция процесса (но не совсем), некоторые умеренные гарантии того, что контейнер не отключит узел (но никаких гарантий), красивый интерфейс для управления ваш сервер с (не только для контейнеров OpenVZ), и много головной боли, пока вы не настроите его правильно. Я бы избегал OpenVZ для этого конкретного использования.

Если вы категорически настроены на использование Proxmox, я бы предложил использовать для этой цели KVM вместо контейнера OpenVZ. Поверьте, у вас будет меньше головной боли.

В ответ на «не делайте этого из соображений производительности» мы используем Proxmox в среде с очень большим объемом записи (70% INSERT), с бэкэндом RAID-10 на ничем не примечательных дисках (WD Red) и несколькими другими загруженными виртуальными машинами. (OpenVZ и KVM) и не имеют проблем с производительностью записи (iodelay редко превышает 0%). Если вы рассматриваете только производительность, тогда не должно быть никаких проблем, если базовое оборудование прилично.

Мудрые преимущества - онлайн-миграция, резервное копирование моментальных снимков, расширение дискового пространства ... все это есть.

Что касается надежности proxmox, могу лишь повторить другой постер.

время безотказной работы

19:51:09 до 785 дней, 22:59, 1 пользователь, средняя загрузка: 4,92, 4,81, 4,79

время безотказной работы

19:51:55 до 142 дней, 4:56, 1 пользователь, средняя загрузка: 0,05, 0,07, 0,05

Для мощного производственного сервера я не вижу смысла использовать контейнер. По моему опыту, реальных преимуществ нет. Может быть, размещение раба или нескольких рабов на контейнерах имеет смысл, но хозяин, я бы поставил это на голый металл. Проверьте кластер Percona. Это круто.

По каким причинам вы хотели использовать виртуальную машину? Что такое бизнес-кейс?

Есть некоторые преимущества запуска MySQL в контейнере.

Контейнеры PVE предлагают несколько преимуществ: - Управлять сервером БД и не влиять ни на что другое - Легко перемещать (онлайн при использовании общего хранилища) на другой физический хост - резервное копирование с помощью PVE, хотя, на мой взгляд, лучше использовать xtrabackup или Idera Hot Copy - Запуск 2 или более из них в сценарии репликации главный-подчиненный, поэтому у вас есть «живые» резервные SQL-серверы, но это создает единую точку отказа, если они находятся на одном физическом сервере.

Prox очень надежен, в этом нет никаких сомнений - у меня есть серверы proxmox, время работы которых составляет 800 дней +. если вы работаете в контейнерах, производительность будет незначительной. Просто убедитесь, что вы выделили ядра процессора для виртуальной машины, чтобы innodb мог их использовать.