Тяжелое производство База данных MySQL/Percona в openvz контейнере

Nick - Вы использовали Linux прежде? Если так, затем необходимо быть знакомы с входом в систему через ssh к IP-адресу, данному Вам, наряду с именем пользователя и паролем.

В противном случае я настоятельно рекомендовал бы нахождение кого-то, кого Вы знаете, кто испытан с платформой и изучением от них!

Быстрое практическое руководство SSH: http://kimmo.suominen.com/docs/ssh/

Устанавливать ftp - yum install vsftpd (http://en.wikipedia.org/wiki/Vsftpd)

что касается phpMyAdmin: http://www.phpmyadmin.net/home_page/docs.php - yum install phpmyadmin

vsftpd.conf я использую.

1
задан 11 February 2014 в 12:17
4 ответа

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

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

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

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

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

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

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

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

1
ответ дан 4 December 2019 в 00:29

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

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

0
ответ дан 4 December 2019 в 00:29

Запуск MySQL в контейнере дает некоторые преимущества.

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

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

0
ответ дан 4 December 2019 в 00:29

В ответ на «не делайте этого из соображений производительности» мы используем Proxmox в среде с очень большим количеством операций записи (70% вставок), с бэкэндом 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

0
ответ дан 4 December 2019 в 00:29

Теги

Похожие вопросы