Каковы общие стратегии управления несколькими базами данных на виртуальном хостинге?
Я много читал в интернете, включая канонические ответы на сервере. Тем не менее, я до сих пор не могу найти ответ на вопрос - What are common strategies for multiple database management in shared hosting?,
До сих пор я узнал, что компании с общим хостингом, как правило, для баз данных SQL поддерживают отдельные серверы. Хорошо. Но мы можем легко понять, что каждая база данных увеличивается в размерах, и раньше или позже пространство, необходимое для всех баз данных, может превышать пространство одного определенного сервера.
Единственное решение, которое пришло мне в голову, заключается в следующем - когда клиент делает заказ, он указывает размер базы данных (например, 50 МБ). Хостинговая компания, имеющая, например, сервер на 500 ГБ, знает, сколько у него может быть баз данных, потому что клиенты заранее определяют пространство. Однако у этого решения есть очень серьезный недостаток - когда клиентские базы данных растут, и ему нужно больше места, но текущий сервер выходит за пределы размера, поддержка должна будет остановить клиентскую базу данных, чтобы переместить ее на другой сервер. К тому же для этого потребуются дополнительные настройки на сайте (минимальный IP). Однако согласно договору хостинг-компания должна обеспечить круглосуточную работу базы данных.
1 ответ
Проектирование хостинговой инфраструктуры 24/7/365 с SLA 100% времени безотказной работы не является тривиальной задачей.
В мире серверов хранилище обычно управляется отдельно от серверов приложений или баз данных, которые его используют. Это называется SAN или сетью хранения данных. Дисковое пространство на уровне блоков выделяется серверам, которым это необходимо, с использованием протокола, такого как iSCSI или Fibre Channel. При использовании такой технологии SAN хранилище отображается на сервере, как локально подключенный жесткий диск, и может быть отформатировано и доступно с помощью инструментов файловой системы сервера, как физически подключенный жесткий диск.
Если вы выделите 500 ГБ пространства из SAN на сервер базы данных, а затем ваше программное обеспечение для мониторинга сообщит вам, что вы приближаетесь к емкости, вы просто увеличите объем этого выделения с 500 ГБ до 600 ГБ из SAN. Сервер теперь будет думать, что он подключен к жесткому диску на 600 ГБ, но только 500 ГБ отформатированы. Теперь вы можете увеличить раздел, используя инструменты файловой системы, предоставляемые ОС на сервере базы данных.
Вы можете создать свою собственную сеть SAN, используя готовые компоненты и технологию с открытым исходным кодом, или вы можете приобрести проприетарное устройство, которое вы просто устанавливаете в своей серверной комнате. В любом случае SAN будет поддерживаться каким-либо дисковым массивом, который будет иметь уровень управления логическими томами поверх физических дисков. Это будет в форме RAID, ZFS, LVM и т. Д. Пока есть пустые отсеки для дисков, вы можете просто добавить дополнительные жесткие диски и использовать соответствующие инструменты управления для увеличения логического тома. Это дает вам больше места, которое вы можете позже выделить серверам.
Конечно, для соответствия 100% времени бесперебойной работы SLA вам потребуется кластер высокой доступности или, по крайней мере, некоторая форма репликации с балансировщиком нагрузки, который может автоматически перенаправлять трафик.
Я не могу говорить о мире Windows, но кое-что, что вы, возможно, захотите рассмотреть с точки зрения хранения в Linux: iSCSI, CLVM, GFS2, DM-Multipath.