|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день. Есть сервер, с openvz на борту, сейчас крутиться 3 виртуалки, поэтапно на него будут переноситься все функции, которые лежали на других физических серверах. Сейчас там только zabbix, биллинг и прочие мелочи. Почти все работают на mysql. Поэтому задался вопросом, как правильно организовать связку с mysql. Возможные варианты:
1. В каждой виртуалке mysql для тех служб что работают в конкретной виртуалке. Из плюсов - надежность, если упадет в одной виртуалке база, другие будут работать дальше. Из минусов - большее потребление ресурсов.
2. Сделать отдельную виртуалку, чисто для mysql.
3. Поставить mysql на хосте.
Мне больше нравиться второй вариант. Но пока еще не делал подобного. Поэтому хотелось бы узнать, если кто-то уже подобное делал, есть какие либо подводные камни.
Неактивен
Очень сильно зависит от условий. Я бы выбрал первый вариант, чтобы реализовать то, что требуется от виртуалок, а именно логическое отделение проектов. При этом потребуется несколько больше памяти, но зато сможете настроить параметры сервера по-разному для каждой виртуалки. Еще есть плюс на многоядерных системах - глобальные мьютексы MySQL (например, query cache) будут разделены на три части. Кроме того, разные проекты не будут конкурировать за общие кэши (key_buffer, innodb_buffer_pool) и выбивать друг друга из общих кэшей.
Неактивен
as_lan написал:
Добрый день. Есть сервер, с openvz на борту, сейчас крутиться 3 виртуалки, поэтапно на него будут переноситься все функции, которые лежали на других физических серверах. Сейчас там только zabbix, биллинг и прочие мелочи. Почти все работают на mysql. Поэтому задался вопросом, как правильно организовать связку с mysql. Возможные варианты:
1. В каждой виртуалке mysql для тех служб что работают в конкретной виртуалке. Из плюсов - надежность, если упадет в одной виртуалке база, другие будут работать дальше. Из минусов - большее потребление ресурсов.
2. Сделать отдельную виртуалку, чисто для mysql.
3. Поставить mysql на хосте.
Мне больше нравиться второй вариант. Но пока еще не делал подобного. Поэтому хотелось бы узнать, если кто-то уже подобное делал, есть какие либо подводные камни.
Вообще на мой взгляд, тут важен факт, что именно находится на самой базе.
То есть, есть ли в базе, какая то общая информация для всех проектов ? (и планируется ли это на будущие)
Если общей информации нет, то первый вариант однозначно лучше по причинам перечисленными вами и rgbeast,
могу к ним добавить: зависимость между проектами в плане отказоустойчивости и полное восстановление снепшота например. Также если не грамотно разграничить права доступа, то могут быть проблемы с безопасностью, а в случае с отдельными виртуалками, проблема отпадает сама по себе.
Неактивен
Общих скорее всего не будет. А как насчет производительности? Очень критично. Не пострадает ли она при таком разделении? Ведь системных ресурсов потреблять будет больше. Сейчас там крутиться битриксовский сайт на первой виртуалке, база файрбёрд на второй, и скоро надо переносить zabbix, биллинг и еще пару служб на Mysql. Общей информации не будет.
Неактивен
А почему Вы считаете, что ресурсов будет потребляться больше? Это же настраиваемо всё?
Неактивен
ну как, на каждой виртуалке если он будет запущен в любом случае будет потреблять чуть больше, чем если будет на одном осте запущенно но с несколькими базами. По крайней мере логически если рассуждать так получается 
Неактивен
Да, чуть больше памяти при нулевой загрузке. Когда вы создали виртуалку, вы сознательно на это пошли - чуть больше памяти потребуется для апача, для ядра, для системных процессов. Однако, если предполагать серверы загруженными, то разделение может дать выйгрыш по памяти и ряд других плюсов. Если у вас 1 гигобайт памяти на все, то вопрос об общем MySQL имеет смысл, а если 8 или 16 гигов, то точно лучше разделить.
Неактивен
Ок, спс, так и будем делать. А разделил так как для некоторых сервисов требуются свои версии php и прочих составляющих. Их при всем желании не получалось на один сервер посадить.
Неактивен
Почему же нет? Никто не мешает поставить разные версии приложения по разным
путям и наслаждаться. Ну или chroot.
Хотя, конечно, на современных технологиях виртуалки и правда проще.
Неактивен
