В настоящее время у нас есть активный-активный 2-узловой кластер с виртуальными машинами. У каждого узла есть два диска, каждый диск является зеркальным DRBD на другом узле. Каждый узел запускает виртуальные машины на своем основном устройстве drbd, а кластер кардиостимулятора будет обрабатывать отказоустойчивость (в случае сбоя одного узла другой становится основным на обоих устройствах drbd и запускает все виртуальные машины). Это размещено в центре обработки данных, поэтому наши затраты (помимо приобретения оборудования) зависят от того, сколько стоек мы занимаем.
Когда вы начинаете с малого, это отличное решение, оно умещается в стойке 2U (предположим, что коммутатор (ы) Ethernet уже есть) и на 100% избыточен. Но это также немного сложная настройка, и она страдает, когда нагрузка ввода-вывода становится слишком высокой (я думаю, это просто из-за небольшого количества шпинделей).
Мне интересно, какое решение может быть лучшим для масштабирования, превышающего возможности нашего оборудования, при этом при этом оно будет экономически эффективным и будет настолько избыточным, насколько это разумно:
Разделение серверов хранения и приложений кажется мне наиболее гибким и разумным решением, мы могли бы легко добавить дополнительные узлы хранения, когда это необходимо, и по-прежнему использовать текущие серверы приложений или сделать наоборот, когда мы достигнем пределов емкости.
Как вы думаете, какой выбор хорош / плох? У вас уже есть опыт работы с подобными вещами без больших бюджетов (я стараюсь исключить оптоволоконный канал или устройства хранения за 10000 евро)?
РЕДАКТИРОВАТЬ: Чтобы быть ясным, идея заключается в том, что, используя современное (и бесплатное) программное обеспечение, вы можете реализовать избыточность, просто добавив больше «стандартного» оборудования. Это не будет кричать ни быстро, ни сверхвысокой доступности, но это позволит нашей виртуальной машине работать, даже если материнская плата выйдет из строя столько, сколько потребуется, чтобы получить запасной для DC и заменить часть.
РЕДАКТИРОВАТЬ: Я удалил упоминание USB, потому что он действительно никуда не денется (и спасибо, что указали на это в ответах). Не знаю, как я забыл о корпусах SAS. Как пример с веб-сайта Dell, MD1000 имеет размер 2U со ссылками SAS. Два корпуса подключены к двум узлам хранения через SAS, и они могут обеспечивать резервирование и экспортировать iSCSI.
Первые USB-диски никогда не дадут вам хорошей производительности.
Кажется, вам нужны две вещи, которые обычно не сочетаются. Полностью избыточное высокодоступное решение за небольшие деньги или вообще бесплатно. Избыточность стоит дорого, особенно если вам нужно больше опций. На нижнем уровне резервных решений у вас есть решения хранения EMC, NetApp и Dell Equallogic меньшего размера. Все они поддерживают iSCSI и Fibre Channel, поэтому вы можете подключаться к ним, когда захотите. Практически все они начинаются с размера 4-5U и затем развиваются. Это дает вам хорошую платформу хранения, на которой вы можете построить свой виртуальный кластер.
Выполнение репликации хранилища на основе хоста с внутренних дисков в одном устройстве на внутренние диски в другом устройстве просто не масштабируется надолго. В конце концов сеть исчерпает пропускную способность, или диски не смогут справиться с нагрузкой, которой вы их подвергаете. И репликация в основном удваивает нагрузку на диски, поскольку каждая запись на диски должна быть прочитана, а затем передана по сети на другой хост для записи туда. Плюс ко всему, что должно происходить и в пульсирующем трафике.
Если бизнесу необходимо иметь решение для обеспечения высокой доступности, им действительно стоит спланировать его оплату. Если вы будете делать это по дешевке, это сработает только на определенное время и в конечном итоге укусит вас.
Вы определенно хотите разделить диски и виртуальные машины, потому что вам нужно, чтобы узлы виртуальных машин имели доступ к общему хранилищу (а не отдельному зеркальному хранилищу), чтобы операции переключения при отказе выполнялись практически без проблем. Я бы отказался от кластеризации на уровне ОС в пользу кластеризации на уровне виртуальных машин, поскольку, по моему опыту, хранилища данных, как правило, являются более уязвимыми точками, чем оборудование и ОС (при условии, что ОС настроена на стабильность), и проблемы на уровне ОС, влияющие на один узел кластера имеет тенденцию переноситься на другой узел (плохие обновления, проблемы netowrk и т. д.), что делает кластеризацию ОС неэффективной. У виртуальных машин должны быть локальные диски только для запуска гипервизоров, но диски виртуальных машин должны находиться в общем хранилище (и вам понадобится это общее хранилище, по крайней мере, на аппаратном RAID5). Размещение виртуальных машин в кластере общих ресурсов (а-ля VMWare) - лучший способ, поскольку он позволяет выполнять очень детальную автоматическую балансировку нагрузки. При такой настройке добавление нового оборудования к настройке сводится к добавлению нового сервера виртуальной машины к общему диску, размещению на нем гипервизора и присоединению его к кластеру.
У меня нет никаких рекомендаций по типу общего хранилища, поскольку люди, знакомые с миром общего хранилища и виртуальных машин, как правило, имеют очень хорошие данные, и я полагаюсь на их мнение.
Единственный способ добиться значительного улучшения ввода-вывода в центрах обработки данных ... - это инвестировать в сумасшедшие объемы выделенной полосы пропускания между центрами обработки данных. Кластерные файловые системы в значительной степени зависят от минимальной задержки и высокой пропускной способности, чтобы иметь возможность работать хорошо. Когда есть задержка ... узкое место ввода-вывода экспоненциально хуже. (1-10 мс - это хорошо, неплохо ... 10-30 мс - это не очень ... 30 мс + довольно плохо.)
Есть несколько способов снизить некоторые из этих накладных расходов ... с помощью Другой методы хранения ... например, хранилище S3 ... или простая реплицируемая файловая система.
Обратной стороной является то, что, поскольку они реплицируются ... если одна сторона обновляет файл почти одновременно с другой или одна сторона обновляет файлы слишком часто ... вы получаете несвязную репликацию ... что может быть кошмар, чтобы разобраться. Эти типы хранилищ отлично подходят, если вы делаете нечастые коммиты ... и много операций чтения.
Попытка реализовать такие вещи, как Amazon EBS ... или S3 по дешевке, в лучшем случае маловероятна. У них гораздо больший бюджет и ОГРОМНАЯ пропускная способность между центрами обработки данных, с которой можно играть.