Будет ли (по сути) стабильным вложенный Xen SR?
Является ли эффективно вложенное хранилище Xen Server проблемой для стабильности?
Рассмотрим рисунок пути данных веб-сервера к физическому диску: (начиная справа)
На графическом сервере Xen и VM сервер DRBD / NFS размещен на внутренней USB-флешке. Жесткие диски представляют собой локальный массив MDRAID10. Другие виртуальные машины будут храниться в репозитории хранилища через NFS на DRBD через VDI, подключенный в качестве блочного устройства к массиву MDRAID. VMS - это обычно Debian. У нас НЕТ выделенного общего запоминающего устройства (NAS, SAN и т. Д.).
Если производительность не является проблемой (5-10 малоиспользуемых пользователей для спорадического веб-доступа к сайту компании с места), возникнут ли проблемы со стабильностью на основе пути к данным, являющегося хранилищем, обслуживаемым другим хранилищем репозитория через NFS на DRBD.
TL; DR
Вместо двойных сетей SAN с поддержкой сети мы пытаемся использовать DRBD на двух серверах с локальным хранилищем, чтобы обеспечить простое переключение вручную при сбое на основном сервере. Во время сбоя вторичный сервер станет первичным, и виртуальные машины (теоретически) могут быть мгновенно запущены с очень небольшой настройкой. Серверы имеют одинаковые поколения RAM и CPU.
У Xen, похоже, есть свои причуды, и я предвижу, что у Xen Server возникнет проблема, которая уничтожит весь сервер, пока он не будет «исправлен», учитывая, что Xen запускает ВСЕ. Я сомневаюсь, что у нас будет безвозвратная потеря данных, но исчезновение репозиториев хранилища происходит гораздо чаще, чем я мог бы подумать на основании чтения; и если все ваши утки аварийного восстановления не находятся в идеальном маленьком ряду, может потребоваться некоторое время, чтобы восстановить все правильно, если нам придется переустанавливать Xen с нуля, тщательно заполняя пробелы, которые нам не хватало в нашей документации, когда мы шли .
С мыслью о DRBD в случае возникновения проблемы мы могли бы очень быстро запустить наш сервер резервного копирования с активными зеркалами файлов и виртуальных машин. В худшем случае мы могли бы легко начать с нуля на основном сервере, если это необходимо, и не беспокоиться о «исправлении» чего-либо.
То, что не показано, - это еще пара VMS для обслуживания файлов, но данные будут размещены на другом SR, поэтому только сами данные виртуальной машины, которые являются довольно статичными, будут обслуживаться тем же путем, что и на рисунке.
После запуска этой установки в производственной среде в течение 6 месяцев я могу сказать, что, похоже, нет никаких проблем со стабильностью виртуальных машин, работающих на SR, обслуживаемых DRBD в виртуальной машине.
Самая большая проблема заключается в том, что у вас есть два «хоста», о которых нужно беспокоиться, которые повлияют на все другие виртуальные машины, Dom0 и сервер DRBD, эффективно добавив вторую точку отказа программного обеспечения (ошибки конфигурации, ошибки администрирования, ошибки и т. Д.). Однако пока это не проблема.
Я не проводил какой-либо сравнительный тест производительности виртуальных машин на DRBD и вне его, хотя у нас не было никаких заметных проблем с производительностью, и большая часть обслуживаемых данных не обслуживается DRBD; SR на DRBD размещает только диски хоста виртуальной машины.
TL; DR
У нас была некоторая дополнительная оперативная память, доступная на HOST, поэтому я установил сервер DRBD на использование всей оставшейся доступной оперативной памяти, чтобы он кэшировал данные, которые он обслуживает.
Подключить вторичный сервер относительно просто. Он включает в себя настройку службы DRBD серверов резервного копирования на первичный, установку диска DRBD, затем удаление SR первичного сервера и повторное добавление его на вторичный сервер из SR на диске DRBD, а затем использование встроенного резервного копирования и восстановления XenServers для повторного связывания метаданных. на виртуальные диски.
Это означает, что виртуальные машины, используемые во время простоя на основном сервере, никоим образом не устарели, потому что они были активно реплицированы через DRBD вместо сценария. Очень важно поддерживать метаданные в актуальном состоянии, чтобы облегчить эту работу.
Это используется как RAID, и для виртуальных машин по-прежнему создается резервная копия на случай другого сбоя или повреждения.