Я пытаюсь построить архитектуру с виртуальными серверами для хостинга веб-приложений J2EE. У меня нет опыта виртуализации. В настоящее время у меня есть 1 сервер с установленным Apache / Jboss / Postgresq / Proftpd, и я хочу разработать что-то, где службы работают на разных серверах.
1 балансировщик нагрузки HTTP (+ 1 сервер HTTP для отработки отказа) -> несколько серверов приложений или веб-серверов -> сервер базы данных (+ 1 сервер для репликации)
Файлы будут храниться на SAN и 2 серверах для базы данных и балансировщика нагрузки HTTP (не виртуальных)
Вот что я имею в виду: Архитектура
Спасибо !!!
Если ваши балансировщики нагрузки доступны в ненадежных сетях, я бы подумал о том, чтобы установить брандмауэр на серверы приложений и серверы баз данных в разных зонах. Ваши серверные роли уже хорошо распределены по уровням. Кроме того, я бы попытался избежать прямого доступа к моим серверам баз данных для FTP-фермы.
Размещение СУБД на физическом оборудовании - всегда более безопасный вариант. Не виртуализируйте, если вы не стоите спиной к стене, а ваш босс не больше вас.
Получите FC, если у вас есть деньги. Один адаптер iSCSI в 4 раза медленнее, чем один FC HBA. Вы можете достичь теоретической пропускной способности FC, добавив гигабитные адаптеры Ethernet, но вы не получите низкой задержки.
Думали ли вы о размещении своих виртуальных машин (виртуальных машин) в сети SAN? Для виртуальных машин низкая задержка FC имеет большое значение, поскольку виртуальные машины генерируют множество небольших операций ввода-вывода. Для более дешевого варианта NAS для виртуальных машин я предпочитаю NFS, а не iSCSI. Настроить проще, поскольку резервное копирование виртуальной машины - это просто копия папки.
Виртуализация Xen чрезвычайно стабильна и хорошо настроена, что может дать вам действительно хорошую производительность (конечно, нетривиальная задача!). Практически единственные приложения, которые сильно страдают, - это приложения с высокой пропускной способностью, такие как файловые серверы или СУБД. Поэтому разумно разместить БД на реальном сервере, если вы ожидаете большой нагрузки. Все остальное будет ограничено вашей пропускной способностью в Интернете, поэтому их виртуализация не проблема.
О SAN: обычно достаточно использовать iSCSI для хранения Xen, если у вас есть хорошие коммутаторы (узнайте это на собственном опыте! 3Com не так хорош, лучше пойти в HP или Dell). Если БД не вырастет до диапазона TeraByte, я бы использовал внутреннее хранилище (диски SAS 10K или 15Krpm на RAID1, если хотите), а не SAN. Если DB вырастет за пределы этого, лучше инвестируйте в хороший FC SAN (здесь я не могу вам помочь)
В целом нормально, я бы на 100% поместил ваши БД в FC SAN, если вы ожидаете высокой нагрузки, мы запускаем JBoss на RHEL 5U3 от Oracle внутри VMWare ESX 3.5U4, работает очень хорошо, вы можете использовать VMWare HA для аварийного переключения, если ты хотел?
Мой 2c
Без FTP эта диаграмма очень похожа на одну из наших систем, которая у нас отлично работает. Что касается некоторых других ваших замечаний:
У нас есть несколько виртуальных машин RH4 (ESX 3.5) с JBoss, и все они в порядке. Просто помните о требованиях JBoss к памяти при создании виртуальных ящиков.
Если вы можете себе это позволить, я бы определенно выбрал SAN на основе FC, если вы ожидаете высокой пропускной способности или будущего расширения.
По моему опыту, нет большой разницы в производительности между физическим сервером БД с хорошей дисковой подсистемой и виртуальным, имеющим доступ к SAN.
