Является ли хорошей идеей иметь базу данных транзакций на сервере, использующем iSCSI?
Их главный аргумент заключается в том, что у вас может быть два сервера, обращающихся к одному и тому же массиву дисков, поэтому, если один сервер сломается, другой может начать работу.
Так что у меня один сервер в каком-то режиме холодного ожидания. Действительно ли такая установка безопаснее, чем наличие дисков и сервера на одной машине?
Это означает, что iSCSI-машины не так легко ломаются, как сервер.
Другой момент - это WAL, на который может негативно повлиять задержка сети. Есть опыт?
Я рад слышать ваше мнение по этой теме.
Ваш вопрос должен быть разбит на две части: внутреннее и внешнее хранилище и iSCSI против альтернатив (FC, FCoE, NFS). Мой опыт работы с крупными корпоративными клиентами, использующими в основном Oracle, поэтому это может не относиться к меньшим средам или другим базам данных. На мой взгляд, внешнее хранилище имеет большую ценность; iSCSI - один из вариантов для обеспечения этого, но он не так развит, как некоторые из альтернатив.
Внутреннее и внешнее хранилище
Внешнее хранилище, обычно предоставляемое в виде дискового массива и представленное через сеть хранения данных (SAN), обеспечивает ряд преимуществ:
Основными недостатками внешнего хранилища являются сложность и стоимость настройки и обслуживания сети хранения данных и массивов хранения.
iSCSI и альтернативы
Fibre Channel в настоящее время является стандартным механизмом доступа к внешнему хранилищу для баз данных. Обычно SAS (Serial-Attached-SCSI) используется для менее важных данных, скорее как расширение внутреннего диска, чем как диск в SAN. Ключевым моментом этих технологий является то, что они работают в выделенных сетях хранения.
Новые альтернативы, такие как FCoE и iSCSI, фактически обеспечивают тот же протокол, что и FC и SAS, за исключением того, что они работают через Ethernet и, следовательно, могут использовать ту же инфраструктуру, что и для сетей типа «хост-хост». Идея состоит в том, что за счет конвергенции Ethernet компании могут снизить стоимость и сложность использования внешнего хранилища. Тем не менее, все еще возникают вопросы о том, обеспечивает ли Ethernet как транспорт скорость и надежность выделенных технологий.
NFS - это протокол файлового уровня, который также работает через Ethernet. В прошлом считалось, что это слишком много накладных расходов для баз данных, но с аппаратной разгрузкой в новых сетевых адаптерах, улучшенными сетевыми стеками ОС и прямой поддержкой базой данных (например, функция Direct NFS в Oracle) это также жизнеспособный вариант для некоторых компаний. NFS особенно удобен, поскольку сокращает объем администрирования, связанного с изменением размера томов, а также подходит для модели виртуализированного хранилища, такой как EMC VNX и Oracle ZFS Storage.
В моем мнение iSCSI менее стабилен для транспорта сети хранения, чем Fibre Channel или Fibre Channel over Ethernet. Предполагая, что вы сделали необходимые оптимизации, он должен работать. Лучше всего будет работать, если соединение iSCSI будет проходить через выделенный Ethernet-канал, и на нем не будет трафика, отличного от iSCSI. Инициаторы ISCSI с годами стали лучше и даже теперь поддерживают многопутевость, если хотите.
Что касается запуска транзакционной базы данных через iSCSI, у меня есть сомнения. Сервер с холодным резервом должен иметь возможность продолжить работу с того места, где остановился горячий сервер, предполагая, что он оставил файлы базы данных в восстанавливаемом состоянии. Тем не менее, единственный вариант использования, в котором выделенные транспортные сети хранения действительно эффективны, - это вариант использования «большого количества мелких транзакций».
В конце концов, по моей оценке, это сработает, но может катастрофически выходить из строя чаще, чем при использовании FC или FCoE.
Вы подняли пару разных вопросов. Во-первых, может ли iSCSI хорошо работать с транзакционной базой данных? Да, конечно. Но однозначно да. В большинстве реализаций вы получите лучшую производительность от волокна. Вам необходимо понять свои требования к вводу-выводу, чтобы определить, действительно ли вам нужна такая производительность. В противном случае iSCSI может быть идеальным. При этом иногда случается, что люди видят, насколько легко реализовать iSCSI, поэтому они просто развертывают его, не задумываясь о проектировании. Лучшие практики для iSCSI легко найти в Google, но вы должны подумать о таких вещах, как то, как вы будете отделить этот трафик от другого трафика (выделенные коммутаторы или VLAN), как вы можете реализовать jumbo-кадры, будете ли вы использовать MCS или MPIO ( ваш поставщик, вероятно, продиктует это за вас) и т. д.
Вторая проблема заключается в том, как вы собираетесь создать избыточность для своих баз данных. Да, это правда, что в случае отказа основного сервера вы можете назначить эти диски другому устройству, но я бы не стал полагаться на это как на свое решение высокой доступности, потому что вам не гарантируется, что умирающий основной сервер оставит эти базы данных в хорошем состоянии. Есть много способов сделать HA, и большинство из них хорошо работают с iSCSI, но вам нужно подумать над этим.
Мы использовали iSCSI-внешнее хранилище в нашей среде транзакционной базы данных Oracle в течение многих лет без проблем и с отличной производительностью. Однако компонент iSCSI не является частью нашего плана резервирования. Мы обращаемся к этому, как показали другие. Кроме того, по причинам, также упомянутым в противном случае, мы переходим на хранилище на основе NFS с использованием Oracle DNFS. С 11gR1 мы увидели довольно много проблем, которых, похоже, нет в 11gR2. У нас еще недостаточно пользователей, чтобы увидеть, как действительно будет работать производительность. Вероятно, это произойдет в ближайшие несколько недель.
Ваш план серьезно ошибочен, потому что производительность при использовании iSCSI будет явно ниже, чем при использовании локальных дисков. Кроме того, существуют схемы лучше, чем холодный резерв для доступа к одним и тем же дискам, который также страдает от единственной точки отказа, являющейся наиболее ненадежной частью - дисков.
Я предлагаю вам использовать более традиционный подход, который был хорошо протестирован и доказал свою эффективность. Используйте локальные диски на обеих машинах и используйте репликацию master / slave или master / master для обеспечения избыточности.
Существует множество дисковых массивов SAS, которые позволяют подключать несколько серверов. Например, массивы Dell MD32x0 при настройке с двумя контроллерами могут работать с четырьмя серверами с двумя избыточными подключениями на каждый сервер (http://www.dell.com/downloads/global/products/pvaul/en/powervault-md3200-md3220-transition-guide.pdf).
Если у вас нет особой необходимости создавать среду SAN, вы никогда раньше не использовали SAN и просто хотите активный / резервный отказоустойчивый режим, это будет более простым, легким и дешевым решением.