Как подключить схд к серверу
Как подключить схд к серверу
Подключение СХД к серверу по оптике позволит максимально использовать технический потенциал дисковой подсистемы. При помощи услуги клиент обретает такую систему хранения данных, которая максимально соответствует его текущим потребностям.
Подключение СХД возможно следующими способами:
1. DAS — наиболее простой вариант подключения, при котором сервер полностью управляет дисковой подсистемой. Выгодно для тех случаев, когда важна скорость доступа к данным и простота всей системы, не требующая длительной настройки или внедрения. Подключение СХД к серверу требует поиска такой организации системы, при которой сервер и устройство хранения данных будут расположены рядом.
2. NAS — при таком подключении дисковая подсистема доступна пользователям в виде одновременно используемых файлов или директорий в собственной файловой системе. Для этого способа подключения характерны протоколы доступа к файлам SMB (CIFS) и NFS. Связь налаживается по сети, а значит, хранилище данных может быть удалено от пользователей системы. Многие комплексы с таким типом подключения оснащаются дополнительными опциями: снятие образов хранилища, дедупликация или компрессия данных.
3. SAN — компромиссный вариант, в котором сочетается простота и скоростные показатели DAS с гибкостью настройки NAS, а клиент получает максимальную отказоустойчивость. Для него характерно разделение дисковой подсистемы на логические блоки, доступ к которым имеет не единственный сервер, а все пользователи сети. Подсистемы не зависят от компонентов SAN, обращение идет к хранилищу данных посредством блочного типа доступа, а сами устройства хранения данных могут быть территориально удалены от клиентов.
Подключение СХД к двум серверам — минимально достаточный набор для построения отказоустойчивого кластера по технологиям серверной виртуализации. Система будет работать надежно. Так, отказоустойчивость обеспечивается на аппаратном уровне — при выходе из строя одного элемента работа будет оперативно восстановлена.
Для тестирования ПО на разных платформах, оказания техподдержки, обеспечения безопасности основной системы (в особенности при работе с множеством файлов, поступающих из непроверенных источников) целесообразно использовать виртуальные машины. В такой ситуации потребуется подключение СХД к VMWare.
База знаний wiki
Продукты
Статьи
Содержание
iscsi подключение к схд сервера под windows
Задача:
Как настроить подключение к блочному устройству на системе хранения по протоколу iSCSI?
Решение:
Для работы с блочным устройством через протокол iSCSI необходимо выполнить следующие условия:
Терминология iSCSI
Установка и подключение сетевой карты
В ходе заказа услуги следует сообщить параметры сетевых адаптеров которые вы предполагаете выделить для работы с СХД. Или заказать установку дополнительных адаптеров.
После установки адаптеров и настройки сетевого оборудования сетевой инженер сообщит вам адреса которые вам нужно будет настроить на ваших адаптерах.
Проверка доступности
Наличие второго интерфейса позволит агрегировать (объединить) производительность обоих портов и обеспечит живучесть при обрыве связи по одному из каналов.
Для подключения к таргету вам следует убедиться, что сеть хранения доступна для вашего сервера.
Если у вас один сетевой порт, то вы должны видеть или первую или вторую пару адресов.
Проверьте доступность командой
Настройка Инициатора
Найдите в контрольной панели iSCSI Initiator
Control Panel>System and Security>Administrative Tools>iSCSI Initiator
Имя IQN текущего инициатора можно посмотреть на закладке:
Имя инициатора
Пример: iqn.2009-01.net.colobridge:ad321
Во избежание лишних недоразумений рекомендуем использовать имя сервера которое мы назначили вашему серверу, например, вы можете найти это имя в списке ваших услуг:
Портал > Панель клиента > Продукты/услуги > Dedicated Flex +, ad060.colobridge.net
Из всего этого используете ad060 и настраиваете на своем сервере имя инициатора iqn.2009-01.net.colobridge:ad060
При этом имя хоста в параметрах операционной системы может быть каким угодно.
И имя IQN может быть любым, просто нам удобнее вести учет выдачи ресурсов по нашим внутренним спискам.
Аутентификация
Вам потребуется настроить аутенификацию для discovery и аутенификацию для подключения.
Придумайте или сгенерируйте криптостойкий пароль 14-16 символов
Для создания учетной записи вашего сервера на системе хранения передайте следующую информацию:
После получения этой информации администратор системы хранения создаст учетную запись для вашего сервера с соответствующими вашему заказу LUN и параметрами отображения.
В панели iSCSI Initiator Properties перейдите на закладку Discovery, нажмите Discover Portal, укажите IP-адрес, нажмите Advanced, поставьте птицу на чекбоксе Enable CHAP log on. В качестве имени используйте имя инициатора, пароль 14-16 символов.
Повторите эти действия для каждого из адресов iSCSI портала.
После этих действий на закладке Targets должны отображаться 4 тергета в окне Discovered targets. Если у вас только одна карта, то там должен быть список из двух таргетов.
Последовательно укажите на каждый из таргетов и нажмите кнопку Connect. Затем Advanced, поставьте птицу на чекбоксе Enable CHAP log on. В качестве имени используйте то же самое имя инициатора и пароль 14-16 символов.
В менеджере дисков вы должны увидеть новый диск или диски с размерами соответствующими заказанным. Если этого нет, обновите список устройств через менеджер дисков или менеджер устройств.
Так как ваш сервер видит СХД по нескольким путям, то вместо одного диска вы будете видеть 4.
UltraPath
Разумеется, вы можете использовать стандартный multipath из вашей операционной системы. Однако Huawei UltraPath скорее всего окажется надежнее.
Скачайте и установите пакет UltraPath for Windows. Ссылку для скачивания последней версии пакета вам передаст служба технической поддержки. Или вы найдете ссылку под этой статьей.
Преимущества Huawei UltraPath
После установки перезагрузите сервер.
Убедитесь, что драйвер UltraPath установлен и работает:
Теперь нужно запустить консоль Ultra-Path, зайти в меню System > Global Settings и установить параметры как на этом снимке:
Зайдите в менеджер дисков, активируйте диск, создайте раздел с файловой системой.
В консоли Ultra-Path выберите все пути (1), запустите Performance Monitor (2), выберите тип измерений / measurement (3), запустите мониторинг (4), дайте нагрузку на диск и убедитесь что данные передаются по всем путям.
Тестирование производительности
Для теста производительности рекомендуем использовать утилиту diskspd
Для tier-2 и tier-3 это может длится довольно долго несмотря на то, что вы выбрали быстрое форматирование
Test-1
Это нагрузочный тест с имитацией работы OLTP позволяющий оценить нагрузочные характеристики диска.
Значение опций:
Test-2, Test-3
Эти тесты служат для оценки ширины канала связи с СХД
test-2: последовательное чтение блоками по 512K
test-3: последовательная запись блоками по 512K
Пример результатов тестирования
Тестирование производилось ночное время при небольших конкурирующих нагрузках и без лимитирования SmartQoS
Использовался один порт 10GbE Intel X520 (MTU=9000) на стороне хоста и два порта на стороне СХД с Huawei UltraPath-8.06.063.
В некоторых тестах вы можете заметить малую разницу между различными Tier. Этот эффект объясняется особенностями работы кэша и контроллера СХД. При значительных конкурирующих нагрузках этот эффект делится между клиентами в соответствии с уровнем приоритета tier.
Подключение СХД Qsan к серверам в среде Windows Server и Hyper-V
Мы продолжаем цикл публикаций из серии How To для пользователей СХД Qsan. В данной статье пойдет речь о подключении СХД к серверам на базе Windows Server, в том числе при использовании функционала виртуализации Hyper-V.
В статье мы будем рассматривать подключения СХД Qsan с использованием блочных протоколов доступа iSCSI и Fibre Channel. Сам процесс подключения можно разделить на несколько основных этапов:
В статье приведены скриншоты настройки операционной системы Windows Server 2016/2019 с нелокализованным интерфейсом. Часть описания, не относящаяся напрямую к ОС, взята из нашего предыдущего обзора по настройке ESXi.
Физическая и логическая коммутация
Совокупность оборудования и линий связи между СХД и серверами образуют так называемую SAN сеть. Отказоустойчивое подключение участников SAN сети подразумевает постоянное наличие хотя бы одного пути между инициатором (хост) и таргетом (СХД). Т.к. СХД сейчас практически поголовно имеют минимум два контроллера, каждый сервер должен иметь связь с каждым из них. В простейшем варианте серверы подключаются к СХД напрямую. Такой режим работы называют Direct Attach. СХД Qsan поддерживают такой режим работы. В этом случае каждый сервер должен иметь двухпортовую HBA для соединения с каждым контроллером СХД. Т.е. между сервером и СХД будет 2 пути. При наличии максимального количества опциональных портов в таком режиме к СХД можно подключить до 10 серверов через iSCSI или до 8 серверов через Fibre Channel.
В большинстве случаев серверы соединяются с СХД через коммутаторы. Для большей надежности их должно быть два (в общем случае их, конечно же, может быть больше, но это они все равно делятся на две группы – фабрики). Этим выполняется защита от выхода из строя самого коммутатора, линка и порта контроллера СХД/HBA. В этом случае каждый сервер и каждый контроллер СХД подключается к каждому коммутатору. Т.е. между каждым сервером и СХД будет 4 пути (в случае двух коммутаторов).
Для Qsan параметр MTU меняется на каждом порту каждого контроллера в меню iSCSI Ports
В Windows Server параметр MTU меняется в настройках драйвера адаптера:
Control Panel\Network and Internet\Network Connections → Свойства конкретного адаптера → Configure → Advanced → Jumbo Packet (у некоторых адаптеров этот пункт может называться что-то типа Large Packets)
Для получения инструкций по изменению MTU у физических коммутаторов рекомендуем обратиться к документации конкретного производителя.
Действия на стороне СХД
Необходимые настройки на СХД можно разделить на два этапа:
Настраивать интерфейсы требуется в основном в случае использования протокола iSCSI: необходимо задать IP адреса портов на вкладке iSCSI Ports. IP адреса портов должны быть из разных подсетей, чтобы однозначно маршрутизировался трафик на стороне хоста.
В случае использования интерфейса Fibre Channel ничего настраивать, как правило, не нужно.
Далее необходимо создать пространство хранения. Сначала создается пул – группа физических накопителей, работающих совместно. Пулов в пределах СХД может быть несколько. Накопители внутри пула объединяются в соответствии с выбранным при его создании уровнем RAID, обеспечивая заданную надежность. Пулы создаются на вкладке Pools → Create Pool, где запускается пошаговый мастер.
Помимо обычных пулов Qsan поддерживает создание AutoTiering пулов при условии активации соответствующей лицензии. С принципом работы таких пулов можно ознакомиться в отдельной статье.
После создания пула(ов) необходимо создать тома (volume): Volumes → Create volumes. Также запустится пошаговый мастер создания тома.
Необходимо задать требуемый размер тома, тип тома выбирается как RAID volume. Рассмотрим их более подробно.
Заключительным этапом в настройке СХД является публикация томов для доступа к ним со стороны хостов через функционал LUN mapping → Map LUN.
Действия на стороне хоста
Первоначально необходимо один раз установить на сервере компонент Multipath IO, который обеспечивает работу многопутевого ввода/вывода. Данное действие производится через стандартный диалог Add Roles and Features
При использовании протокола iSCSI необходимо выполнить:
При использовании протокола Fibre Channel все гораздо проще: достаточно выполнить Rescan для обнаружения нового тома. В нашем примере это том с LUN доступный по 4 путям. Как и в случае с iSCSI следует убедиться, что для диска установлена политика Round Robin, при которой все доступные пути до СХД будут использоваться равномерно.
Важное замечание касательно конфигурирования MPIO. По умолчанию Windows видит дисковые устройства по отдельности, т.е. каждый путь к устройству – это отдельный диск.
Чтобы ОС «склеила» все одинаковые диски в единое устройство, необходимо в стандартной оснастке MPIO добавить новое устройство как многопутевое. Для iSCSI устройств устанавливается отдельное разрешение. По окончании настройки потребуется перезагрузить сервер. Данную настройку необходимо произвести однократно для каждой СХД. После чего все вновь презентованные диски будут опознаваться ОС как многопутевые.
В случае использования кластера из нескольких хостов Windows Server, действия, описанные выше, необходимо повторить на каждом из хостов. После чего диски, появившиеся в системе, можно добавлять в дисковые ресурсы кластера.
В рамках этой статьи были рассмотрены преимущественно базовые операции, необходимые для подключения серверов Windows Server к СХД Qsan. Для получения более полной информации настоятельно рекомендуется ознакомиться с руководствами пользователей, предоставляемыми обоими вендорами.
О сетях хранения данных
Решил написать небольшую статейку о сетях хранения данных (СХД), тема эта достаточно интересная, но на Хабре почему-то не раскрыта. Постараюсь поделиться личным опытом по построению и поддержке SAN.
Что это?
Сеть хранения данных, или Storage Area Network — это система, состоящая из собственно устройств хранения данных — дисковых, или RAID — массивов, ленточных библиотек и прочего, среды передачи данных и подключенных к ней серверов. Обычно используется достаточно крупными компаниями, имеющими развитую IT инфраструктуру, для надежного хранения данных и скоростного доступа к ним.
Упрощенно, СХД — это система, позволяющая раздавать серверам надежные быстрые диски изменяемой емкости с разных устройств хранения данных.
Немного теории.
Сервер к хранилищу данных можно подключить несколькими способами.
Первый и самый простой — DAS, Direct Attached Storage (прямое подключение), без затей ставим диски в сервер, или массив в адаптер сервера — и получаем много гигабайт дискового пространства со сравнительно быстрым доступом, и при использовании RAID-массива — достаточную надежность, хотя копья на тему надежности ломают уже давно.
Однако такое использование дискового пространства не оптимально — на одном сервере место кончается, на другом его еще много. Решение этой проблемы — NAS, Network Attached Storage (хранилище, подключенное по сети). Однако при всех преимуществах этого решения — гибкости и централизованного управления — есть один существенный недостаток — скорость доступа, еще не во всех организациях внедрена сеть 10 гигабит. И мы подходим к сети хранения данных.
Главное отличие SAN от NAS (помимо порядка букв в аббревиатурах) — это то, каким образом видятся подключаемые ресурсы на сервере. Если в NAS ресурсы подключаются протоколам NFS или SMB, в SAN мы получаем подключение к диску, с которым можем работать на уровне операций блочного ввода-вывода, что гораздо быстрее сетевого подключения (плюс контроллер массива с большим кэшем добавляет скорости на многих операциях).
Используя SAN, мы сочетаем преимущества DAS — скорость и простоту, и NAS — гибкость и управляемость. Плюс получаем возможность масштабирования систем хранения до тех пор, пока хватает денег, параллельно убивая одним выстрелом еще несколько зайцев, которых сразу не видно:
* снимаем ограничения на дальность подключения SCSI-устройств, которые обычно ограничены проводом в 12 метров,
* уменьшаем время резервного копирования,
* можем грузиться с SAN,
* в случае отказа от NAS разгружаем сеть,
* получаем большую скорость ввода-вывода за счет оптимизации на стороне системы хранения,
* получаем возможность подключать несколько серверов к одному ресурсу, то нам дает следующих двух зайцев:
o на полную используем возможности VMWare — например VMotion (миграцию виртуальной машины между физическими) и иже с ними,
o можем строить отказоустойчивые кластеры и организовывать территориально распределенные сети.
Что это дает?
Помимо освоения бюджета оптимизации системы хранения данных, мы получаем, вдобавок к тому что я написал выше:
* увеличение производительности, балансировку нагрузки и высокую доступность систем хранения за счет нескольких путей доступа к массивам;
* экономию на дисках за счет оптимизации расположения информации;
* ускоренное восстановление после сбоев — можно создать временные ресурсы, развернуть на них backup и подключить к ним сервера, а самим без спешки восстанавливать информацию, или перекинуть ресурсы на другие сервера и спокойно разбираться с умершим железом;
* уменьшение время резервного копирования — благодаря высокой скорости передачи можно бэкапиться на ленточную библиотеку быстрее, или вообще сделать snapshot (мгновенный снимок) с файловой системы и спокойно архивировать его;
* дисковое место по требованию — когда нам нужно — всегда можно добавить пару полок в систему хранения данных.
* уменьшаем стоимость хранения мегабайта информации — естественно, есть определенный порог, с которого эти системы рентабельны.
* надежное место для хранения mission critical и business critical данных (без которых организация не может существовать и нормально работать).
* отдельно хочу упомянуть VMWare — полностью все фишки вроде миграции виртуальных машин с сервера на сервер и прочих вкусностей доступны только на SAN.
Из чего это состоит?
Как я писал выше — СХД состоит из устройств хранения, среды передачи и подключенных серверов. Рассмотрим по порядку:
Системы хранения данных обычно состоят из жестких дисков и контроллеров, в уважающей себя системе как правило всего по 2 — по 2 контроллера, по 2 пути к каждому диску, по 2 интерфейса, по 2 блока питания, по 2 администратора. Из наиболее уважаемых производителей систем следует упомянуть HP, IBM, EMC и Hitachi. Тут процитирую одного представителя EMC на семинаре — «Компания HP делает отличные принтеры. Вот пусть она их и делает!» Подозреваю, что в HP тоже очень любят EMC. Конкуренция между производителями нешуточная, впрочем, как и везде. Последствия конкуренции — иногда вменяемые цены за мегабайт системы хранения и проблемы с совместимостью и поддержкой стандартов конкурентов, особенно у старого оборудования.
Среда передачи данных. Обычно SAN строят на оптике, это дает на текущий момент скорость в 4, местами в 8 гигабит на канал. При построении раньше использовались специализированные хабы, сейчас больше свитчи, в основном от Qlogic, Brocade, McData и Cisco (последние два на площадках не видел ни разу). Кабели используются традиционные для оптических сетей — одномодовые и многомодовые, одномодовые более дальнобойные.
Внутри используется FCP — Fibre Channel Protocol, транспортный протокол. Как правило внутри него бегает классический SCSI, а FCP обеспечивает адресацию и доставку. Есть вариант с подключением по обычной сети и iSCSI, но он обычно использует (и сильно грузит) локальную, а не выделенную под передачу данных сеть, и требует адаптеров с поддержкой iSCSI, ну и скорость помедленнее, чем по оптике.
Есть еще умное слово топология, которое встречается во всех учебниках по SAN. Топологий несколько, простейший вариант — точка-точка (point to point), соединяем между собой 2 системы. Это не DAS, а сферический конь в вакууме простейший вариант SAN. Дальше идет управляемая петля (FC-AL), она работает по принципу «передай дальше» — передатчик каждого устройства соединен с приемником последующего, устройства замкнуты в кольцо. Длинные цепочки имеют свойство долго инициализироваться.
Ну и заключительный вариант — коммутируемая структура (Fabric), она создается с помощью свитчей. Структура подключений строится в зависимости от количества подключаемых портов, как и при построении локальной сети. Основной принцип построения — все пути и связи дублируются. Это значит, что до каждого устройства в сети есть минимум 2 разных пути. Здесь тоже употребимо слово топология, в смысле организации схемы подключений устройств и соединения свитчей. При этом как правило свитчи настраиваются так, что сервера не видят ничего, кроме предназначенных им ресурсов. Это достигается за счет создания виртуальных сетей и называется зонированием, ближайшая аналогия — VLAN. Каждому устройству в сети присваивается аналог MAC-адреса в сети Ethernet, он называется WWN — World Wide Name. Он присваивается каждому интерфейсу и каждому ресурсу (LUN) систем хранения данных. Массивы и свитчи умеют разграничивать доступ по WWN для серверов.
А дальше на системах хранения нарезаются ресурсы, они же диски (LUN) для каждого сервера и оставляется место в запас, все включается, установщики системы прописывают топологию, ловят глюки в настройке свитчей и доступа, все запускается и все живут долго и счастливо*.
Я специально не касаюсь разных типов портов в оптической сети, кому надо — тот и так знает или прочитает, кому не надо — только голову забивать. Но как обычно, при неверно установленном типе порта ничего работать не будет.
Из опыта.
Обычно при создании SAN заказывают массивы с несколькими типами дисков: FC для скоростных приложений, и SATA или SAS для не очень быстрых. Таким образом получаются 2 дисковые группы с различной стоимостью мегабайта — дорогая и быстрая, и медленная и печальная дешевая. На быструю вешаются обычно все базы данных и прочие приложения с активным и быстрым вводом-выводом, на медленную — файловые ресурсы и все остальное.
Если SAN создается с нуля — имеет смысл строить ее на основе решений от одного производителя. Дело в том, что, несмотря на заявленное соответствие стандартам, существуют подводные грабли проблемы совместимости оборудования, и не факт, что часть оборудования будет работать друг с другом без плясок с бубном и консультаций с производителями. Обычно для утряски таких проблем проще позвать интегратора и дать ему денег, чем общаться с переводящими друг на друга стрелки производителями.
Если SAN создается на базе существующей инфраструктуры — все может быть сложно, особенно если есть старые SCSI массивы и зоопарк старой техники от разных производителей. В этом случае имеет смысл звать на помощь страшного зверя интегратора, который будет распутывать проблемы совместимости и наживать третью виллу на Канарах.
Часто при создании СХД фирмы не заказывают поддержку системы производителем. Обычно это оправдано, если у фирмы есть штат грамотных компетентных админов (которые уже 100 раз назвали меня чайником) и изрядный капитал, позволяющий закупить запасные комплектующие в потребных количествах. Однако компетентных админов обычно переманивают интеграторы (сам видел), а денег на закупку не выделяют, и после сбоев начинается цирк с криками «Всех уволю!» вместо звонка в саппорт и приезда инженера с запасной деталью.
Поддержка обычно сводится к замене умерших дисков и контроллеров, ну и к добавлению в систему полок с дисками и новых серверов. Много хлопот бывает после внезапной профилактики системы силами местных специалистов, особенно после полного останова и разборки-сборки системы (и такое бывает).
Про VMWare. Насколько я знаю (спецы по виртуализации поправьте меня), только у VMWare и Hyper-V есть функционал, позволяющий «на лету» перекидывать виртуальные машины между физическими серверами. И для его реализации требуется, чтобы все сервера, между которыми перемещается виртуальная машина, были подсоединены к одному диску.
Про кластеры. Аналогично случаю с VMWare, известные мне системы построения отказоустойчивых кластеров (Sun Cluster, Veritas Cluster Server) — требуют подключенного ко всем системам хранилища.
Пока писал статью — у меня спросили — в какие RAIDы обычно объединяют диски?
В моей практике обычно делали или по RAID 1+0 на каждую дисковую полку с FC дисками, оставляя 1 запасной диск (Hot Spare) и нарезали из этого куска LUN-ы под задачи, или делали RAID5 из медленных дисков, опять же оставляя 1 диск на замену. Но тут вопрос сложный, и обычно способ организации дисков в массиве выбирается под каждую ситуацию и обосновывается. Та же EMC например идет еще дальше, и у них есть дополнительная настройка массива под приложения, работающие с ним (например под OLTP, OLAP). С остальными вендорами я так глубоко не копал, но догадываюсь, что тонкая настройка есть у каждого.
* до первого серьезного сбоя, после него обычно покупается поддержка у производителя или поставщика системы.
Поскольку в песочнице комментариев нет, закину в личный блог.