Я проектирую следующую эволюцию нашей ИТ-инфраструктуры. Я рассматриваю возможность внедрения iSCSI SAN. Мой текущий план состоит в том, чтобы подключить к SAN только наши серверы, а затем реализовать любой общий доступ к файлам для настольных компьютеров через общие сетевые ресурсы, используя один из серверов в качестве файлового сервера. После дополнительного чтения мне интересно, нужно ли мне вообще реализовывать файловый сервер, если у меня есть iSCSI SAN. Вот мои вопросы:
Могу ли я поставить под угрозу производительность SAN для серверов, если позволю трафику SAN проходить по всей сети, а не только между целью iSCSI и серверами в качестве клиентов?
Если я создаю «диск» на цели iSCSI, могут ли несколько клиентов получить доступ к одному и тому же «диску»? Если да, сможет ли это заменить сетевые файловые ресурсы?
Я понимаю, что вопрос 1 - это загруженный вопрос, поскольку я не указывал подробностей моей сети, но я просто ищу общие мысли о том, как двигаться по этому пути. Заранее спасибо за вдумчивые ответы.
Я тоже помню, как задавался этими вопросами.
Вот вам сенсация: сервер видит сегмент iscsi (называемый LUN) так же, как и жесткий диск. Он обращается к нему как / dev / sdwhatever, и вы разбиваете его, используете LVM (если хотите) и создаете файловую систему на этом устройстве. Отлично работает.
Теперь становится сложно, когда вы хотите, чтобы несколько машин одновременно разговаривали с одним и тем же диском. Это все равно, что подключить USB-накопитель сразу к нескольким компьютерам. Безумие. Кошки и собаки лежат вместе. Безумие.
Теперь бывает, что есть несколько способов заставить несколько машин взаимодействовать с одним и тем же устройством, но вы должны использовать так называемую «кластерную» файловую систему. Это файловая система, которая знает, что с ней разговаривают несколько компьютеров, и учитывает это. Он делает это несколькими способами, включая несколько журналов (обычно по одному на машину) или с помощью диспетчера блокировок (который представляет собой один конкретный компьютер, который действует как гаишник), но каким бы путем вы ни пошли, вы будете должны сгруппировать все машины, с которыми вы хотите общаться, с одним и тем же LUN.
Что обычно делают большинство людей, если им нужна действительно высокая доступность, так это объединение трех (а иногда и двух, но это может быть сложнее) компьютеров для совместной работы в качестве кластера файлового сервера. Эти три машины - единственные, кто пишет в LUN, но их клиенты используют NFS, Samba, FTP или что-то еще для доступа к файлам там.
Я действительно сделал Redhat Cluster HOWTO некоторое время назад (http://www.standalone-sysadmin.com/blog/2009/04/howto-redhat-cluster-suite/), но мне так и не удалось добиться стабильной работы. Теперь у меня есть пара машин, настроенных как файловые серверы, на которых не установлен LUN, но могут работать одним нажатием кнопки. Для меня это компромисс, поскольку у меня не было времени изучать пакет кластеризации.
Могу ли я поставить под угрозу производительность SAN для серверов, если позволю трафику SAN проходить по всей сети, а не только между целью iSCSI и серверами в качестве клиентов?
Если вы используете сетевую карту как для iSCSI, так и для обычного трафика, да, однако посмотрите на фактический трафик, который вы отправляете, чтобы получить реальный ответ. Если между серверами и рабочими станциями нет маршрутизатора, накладные расходы на широковещательную передачу рабочих станций немного снизят производительность.
VLAN бесплатны, используйте одну для разделения трафика iSCSI, в наши дни у большинства серверов есть 2xGbe, выделение одной для хранения обычно не проблема.
Если я создаю «диск» на цели iSCSI, могут ли несколько клиентов получить доступ к одному и тому же «диску»? Если да, сможет ли это заменить сетевые файловые ресурсы?
Нет. Это NAS (и, возможно, то, на что вам следует обратить внимание, или, по крайней мере, комбинированное устройство, такое как NetApp).
Там являются "кластерные" файловые системы, которые делают это, однако они требуют, чтобы все хосты были доверенными, и требуется много ручной настройки.
Вы также захотите взглянуть на «зонирование» (так оно называется в мире FC), чтобы убедиться, что Windows (которая примет все, что может получить) не крадет LUN другого хоста (подумайте о разделе)
1) Если я вас правильно понимаю: зависит от того, что вам лучше. Вам нужно несколько серверов для доступа к одним и тем же файлам? Оба прекрасно работают с тем, что они делать, так что это зависит от того, что вам нужно.
2) С конкретными файловыми системами (GFS, OCFS) да. еще нет.
Мы используем оборудование NetApp для нашей SAN, и оно дает нам все возможности
плюс
Это значительно упростило наше хранение. Я занимаюсь переносом 2 ТБ диска с файлового сервера Windows 2003 виртуальной машины VMware на общий доступ непосредственно из самого NetApp. Добавьте возможность делать снимки и резервные копии NDMP прямо на ленту, это то, что нужно учитывать.
Совместное использование SAN напрямую для настольных компьютеров, вероятно, представляет больше проблем, чем оно того стоит, поскольку вам придется установить на рабочие столы специальное программное обеспечение кластерной файловой системы. Это программное обеспечение может быть довольно дорогим для Windows и почти наверняка не принесет вам никакой пользы. Лучше использовать файловый сервер (он может монтировать тома SAN при желании) и стандартные общие ресурсы CIFS.
Некоторое оборудование SAN также может работать в двойном режиме, когда оно экспортирует как хранилище на уровне блоков, так и NAS с использованием обычных протоколов обмена файлами. NetApp наиболее известна этим типом оборудования, хотя вы можете получить системы этого типа от большинства производителей такого оборудования.
Как уже упоминалось, iSCSI значительно усложняет общий доступ. Для этого вам нужны специальные файловые системы (OCFS и т. Д.), И производительность этих файловых систем ниже, чем у других по ряду причин. Например, невозможность использовать память для кэширования, поскольку это препятствует согласованному представлению файловой системы на нескольких хостах, необходимость реализации системы блокировки файлов в самой файловой системе, а не в ядре, поэтому производительность может быть значительно ниже. помедленнее. Это также просто невозможно сделать в Windows, так как в настоящее время для этой платформы нет файловых систем с несколькими монтировками.
Однако, если вы просто хотите предоставить часть диска iSCSI для локального доступа к рабочим станциям и обрабатывать хранилище с общим доступом через файловый сервер с подключенным хранилищем iSCSI, это сработает. Файловые серверы NFS, CIFS или Windows предназначены для обработки такого рода операций в памяти, а не в файловой системе, поэтому производительность может быть намного выше.
Что ж, есть программное обеспечение, которое может быть полезно в вашем сценарии, StarWind iSCSI SAN: это программное обеспечение, которое превращает ваш Windows Server в отличную масштабируемую SAN. Вот некоторые из его наиболее интересных функций:
Не имеет ограничений по емкости отдельного диска, общему количеству установленных жестких дисков, количеству ЦП или ядер ЦП, портам Ethernet или объему ОЗУ. Преобразуйте любой 64-разрядный или 32-разрядный сервер Windows в сеть SAN.
Неограниченные подключения и неограниченный объем хранилища ТБ. Поддерживает кластеры серверов Windows для обеспечения высокой доступности.
Поддержка среды виртуализации для VMware, Hyper-V, XenServer, Virtual Iron. Поддерживает расширенные функции VMware: VMotion, Storage VMotion, HA, DRS и VCB. Общее хранилище для любого серверного приложения, включая SQL Server, Exchange, SharePoint.
Я порекомендую вам сначала воспользоваться бесплатной пробной версией, а потом вы увидите, как все пройдет.
www.starwindsoftware.com
Я бы посоветовал вам взглянуть на Solaris10 + ZFS, так как он в основном может делать все, что файловый фильтр NetApp, за небольшую часть стоимости (iSCSI, снимки RW, CIFS, NFS, кластеризация и репликация), ОС бесплатна для использования и не требует специального оборудования (большая часть Dell / HP x86_64 будет работать нормально).
Привет,
Симона