iSCSI для баз данных, хорошей идеи

По-моему, iSCSI менее стабилен из транспорта сети хранения данных, чем Fibre Channel или Fibre Channel по Ethernet. Предположение Вас сделало необходимую оптимизацию, оно должно работать. Это будет работать лучше всего, если подключение iSCSI пробежится через специализированный Ethernet, никакой нетрафик iSCSI на нем, чтобы помешать. Инициаторы iSCSI поправились за эти годы и даже поддерживают мультисоединение каналом теперь, если Вы хотите пойти туда.

Что касается выполнения транзакционной базы данных по iSCSI, у меня есть свои сомнения. Холодный резервный сервер должен смочь взять, где горячий брошенный сервер, предполагая это оставил файлы базы данных в восстанавливаемом состоянии. Тем не менее один пример использования, где специализированные транспортные сети устройства хранения данных действительно сияют, находится в этом виде "большого количества небольших транзакций" пример использования.

В конце, моей оценкой, это будет работать, но может перестать работать катастрофически чаще, чем использование FC или FCoE.

Ваш вопрос должен быть разломан на две части: внутренний по сравнению с внешним устройством хранения данных и iSCSI по сравнению с альтернативами (FC, FCoE, NFS). Мой опыт с крупными корпоративными клиентами, выполняющими главным образом Oracle, таким образом, это не может относиться к небольшим средам или другим базам данных. По-моему, существует много значения во внешнем устройстве хранения данных; iSCSI является одной опцией для обеспечения этого, но это не является столь же сформировавшимся как некоторые альтернативы.

Внутренний по сравнению с внешним устройством хранения данных

Внешнее устройство хранения данных, обычно настраиваемое в дисковом массиве и представленное через сеть хранения данных (SAN), обеспечивает много преимуществ:

• Высокая производительность, часто с аппаратно ускоренным RAID и большими кэшами с аварийным батарейным питанием.
• Легкий увеличить масштаб объемов для использования большего количества дисков для производительности и способности.
• Централизованный доступ к ресурсам хранения для обхода бункеров потраченных впустую ресурсов.
• Способный совместно использовать устройство хранения данных для высокоэффективных или кластеров высокой доступности (например, Oracle RAС).
• Может идти с функциями данных создания снимков и тиражирования на удаленные сайты.
• Может идти с достойными инструментами аналитики для отслеживания производительности.

Основные недостатки внешнего устройства хранения данных являются сложностью и стоимостью установки и поддержания сети хранения данных и массивов хранения данных.

iSCSI по сравнению с Альтернативами

Fibre Channel в настоящее время является стандартным механизмом для доступа к внешнему устройству хранения данных для баз данных. Распространено видеть SAS (последовательный приложенный SCSI), используемый для менее критических данных, больше как расширение внутреннего диска, чем как диск в SAN. Ключевой пункт об этих технологиях - то, что они работают на выделенных сетях хранения.

Более новые альтернативы, такие как FCoE и iSCSI предоставляют эффективно тот же протокол как FC и SAS, кроме они работают на основе Ethernet и поэтому могут использовать ту же инфраструктуру, используемую для сетей от хоста к хосту. Идея состоит в том, что путем схождения на Ethernet, компании могут уменьшить стоимость и сложность наличия внешнего устройства хранения данных. Однако существуют все еще вопросы вокруг, обеспечивает ли Ethernet как транспорт скорость и надежность специализированных технологий.

NFS является протоколом уровня файла, который также работает на основе Ethernet. В прошлом это, как полагали, имело слишком много служебное для баз данных, но с аппаратными средствами, разгружающимися в более новых сетевых адаптерах, лучших сетевых стеках ОС и прямой поддержке базой данных (например, функция Direct NFS в Oracle), это - также жизнеспособный вариант для некоторых компаний. NFS особенно хорош, потому что он уменьшает администрирование, вовлеченное в изменение размеров объемов, и также соответствует модели виртуализированного устройства хранения данных, такого как EMC VNX и Oracle устройство хранения данных ZFS.

Вы повысили пару других вопросов. Во-первых, iSCSI может работать хорошо на транзакционную базу данных? Да, абсолютно. Но это - квалифицированное да. Вы получите лучшую производительность от волокна в большинстве реализаций. Необходимо понять требования IO, чтобы определить, нужна ли Вам на самом деле та производительность. В противном случае iSCSI мог бы быть прекрасным. Это сказанное, что иногда происходит, - то, что люди видят, как легкий iSCSI должен реализовать так, они просто развертывают его, не много думая о дизайне. Лучшие практики для iSCSI легко найдены на Google, но необходимо думать о вещах как то, как Вы разделите тот трафик от другого трафика (выделенные коммутаторы или VLAN), как Вы могли бы реализовать крупные кадры, будете ли Вы использовать MCS, или MPIO (Ваш поставщик, вероятно, продиктует это для Вас), и т.д.

Второй выпуск - то, как Вы собираетесь разработать дублирование для своей базы (баз) данных. Да, это верно, что, если бы сбои основного сервера можно присвоить те диски другому полю, но я не полагался бы на это как на свое решение HA, потому что Вам не гарантируют это, перестающий работать основной сервер оставил те базы данных в хорошем состоянии. Существует много способов сделать, HA и большинство из них работают хорошо с iSCSI, но необходимо поместить еще некоторую мысль в него.

Мы использовали устройство хранения данных iSCSI-к-внешнему в нашей Oracle транзакционная среда базы данных в течение многих лет без проблемы и превосходной производительности. Компонент iSCSI не является частью нашего плана дублирования как бы то ни было. Мы обращаемся к этому, поскольку другие проиллюстрировали. Также, по причинам, также упомянутым иначе, мы мигрируем на основанный на NFS DNFS Oracle использования устройства хранения данных. С 11gR1 мы видели довольно много проблем, которые, кажется, не присутствуют в 11gR2. У нас нет достаточного количества пользователей все же, чтобы видеть, как производительность действительно удастся. Это, вероятно, происходит за следующие несколько недель.

Ваш план серьезно испорчен, потому что производительность с помощью iSCSI будет отчетливо нижней к наличию локальных дисков. Далее, существуют лучшие схемы, чем наличие холодного резервного устройства для доступа к тем же дискам, который также страдает от единой точки отказа, являющейся самой ненадежной частью - диски.

Я предлагаю, чтобы Вы использовали более стандартный подход, тот, который был хорошо протестирован и доказан работать. Используйте локальные диски n обе машины и ведущее устройство/ведомое устройство использования или основная/основная репликация для обеспечения дублирования.

Существует много дисковых массивов SAS там, которые позволяют нескольким серверное соединение. Например, массивы Dell MD32x0 при конфигурировании с двойными контроллерами могут работать максимум с четырьмя серверами с двумя избыточными соединениями на сервер (http://www.dell.com/downloads/global/products/pvaul/en/powervault-md3200-md3220-transition-guide.pdf).

Если у Вас нет определенной потребности создать среду SAN, никогда не использовал SAN прежде, и просто хотят активную/резервную обработку отказа, это будет более простым, более легким, и более дешевым решением.