Pull to refresh

Comments 44

А почему hostname у NetApp'а «san*»? Ведь NFS это не SAN, а NAS.
Ну во-первых это же просто имя, как хотим так и называем. А во-вторых в тексе описано, что используется IP-SAN (iSCSI).
Кроме того NetApp FAS 2240 может комплектоваться или 10GBE или FC8G карточками и соответственно может одновременно быть как SAN так и NAS устройством.
Упс, невнимательно прочитал, извините)
А про NetApp знаю, да. Даже работаю с ним. Почти родная система :)
Я задам вопрос немного не по теме.

Я с СХД плохо знаком. Информацию просто надо вырывать по кускам у разных людей.
Есть ли просто тупые корзины в которе можно было бы поставить обычные sata, и по SFF соединить с рядом машин? например с тремя.
В народе так и называют корзина для дисков.
Наверно вы про JBOD.
Ну все что я встречал, это расширение для других корзин.
Хотелось бы на текущий момент взять 1u корзину с 4 дисками sata и подключить к серверам. Точка отказа будет корзина.
Бюджет небольшой. Я сам работал с hp 2000p, честно говоря не впечетлен был от устройства за такие деньги.
Если вам нужна отказоустойчивость и плюс к этом вам нужно разделять ресурсы дисков между хостами, значит вам нужна СХД.

Бывают СХД которые могут подключать несколько серверов по SAS. К примеру NetApp E-серия.
Если проблема бюджете на столько велика, то вам однозначто прийдётся крутить что-то на коленке.

К примеру можно взять два сервера настроить кластеризацию или репликацию между ними. Потом настроить доступ к этим серверам, к примеру по iSCSI, NFS или FC (нужно купить HBA адаптеры).

Но это получится та же, но самодельная СХД.
Но зачем тогда их запихивать в одну корзину не пойму, если нужно эти диски раздавать нескольким хостам не пойму.

Стандартная парадигма такова:
Либо вам нужно большое количество дисков для одного контроллера, и здесь просто используются корзины, далее объединение дисков в рейд осуществляется на программном или аппаратном уровне.
Либо вам нужно собрать все диски в одно место объединить их как-то (тут уже тупая железяке на катит), а потом раздавать не диски, а ресурсы на этих дисках нескольким серверам. Это делает СХД.
ЗЫ.
SFF — это Small form factor а не тип подключения. Вы наверное про SAS или SFP.
>Либо вам нужно собрать все диски в одно место объединить их как-то (тут уже тупая железяке на катит), а потом раздавать не диски, а ресурсы на этих дисках нескольким серверам. Это делает СХД.

мне интересно, что бы машины видели один массив жестких дисков. Грубо говоря, если мы СХД подключем по FC к трем или более машинам.
Объединить диски можно средствами OS. Например в Windows 2012 появилась storage space. (можно почитать тут blog.trinitygroup.ru/2013/12/failover-clustered-storage-spaces.html)

Хотя нам надо не для windows.

>Если проблема бюджете на столько велика, то вам однозначто прийдётся крутить что-то на коленке.

На коленках можно сделать, тут уже смотреть в сторону glusterfs или ceph.

В общем примерно нужна железка которая будет тупа без raid и прочих вещей отдавать HDD серверам.

>SFF — это Small form factor а не тип подключения. Вы наверное про SAS или SFP.
SFF 8088 — Внешний мини-SAS — как пример.

upload.wikimedia.org/wikipedia/commons/5/5d/SFF_8088.jpg?uselang=ru
Если вы хотите чтобы одни и теже данные с жестких дисков были видны нескольким хостам, никаким тупым устройством вы этого не сделаете.

Да хоть виндоус ставьте и шарьте один лун по iSCSI нескольким хостам. Тоже самое можно сделать и на Linux.
ну вот пример. www.etegro.ru/configurator/storage/jbod/js300g3

я так понимаю примерно то что мне надо. Полка, отдает по SAS на сервер.
Технология shared DAS. Только вот такой объем дисков не нужен.
На том же сайте, что я писал выше, есть JBODы от 12 дисков, SAS свитч в конфигураторе для организации shared DAS тоже имеется.
Щас меня побьют за рекламу я чую… xD
Я посмотрю. Вообще как правильно называется то что я хочу? Я бы сам попробовал поискать.
Просто когда мы задумывались и была возможность в теории купить схд, сильно смотрели в сторону ibm storwize. После HP 2000 функционал был сказка.
Сейчас к сожелению возможности покупки минимальны, а организовать кластер с миграцией хочется. NAS не подходят по производительности.
Ну а sas, так как остались платы.
Если правильно и дорого, то SAN (Netapp e-серия например), если дёшево и хитро JBOD + SAS свитч… со вторым вариантом на практике не сталкивался, но наверняка там есть какие то проблемы, всегда сопровождающие решения из категории дёшево и хитро :)
Не забывайте ещё и про то, что купить можно за дёшиво, а потом за дорого сопровождать и восстанавливать. А «дорого», это не всегда деньги, иногда это «время».

NAS, SAN и DAS это типы подключений, а не типы СХД. Многие СХД умеют одновременно иметь подключения, к примеру NetApp E-серия может быть как по SAN так и по DAS. FAS серия может быть как по SAN так и по NAS одновременно

NAS не подходят по производительности

Некоторые СХД с подключением по NAS дают миллионы IOps и десятком мс задержки на случайных операция чтения-записи.
То, что по вашей ссылке — это JBOD, т.е. подключая сервер к этой полке, на контроллере сервера вы увидете просто набор дисков и уже на контроллере сервера будете создавать массив RAID из этих дисков. Однако, отданные диски одному серверу, ко второму уже не подключить. Таким образом можно разбить диски этой полки на несколько частей, например 4 диска одному серверу, 4 другому и тд. И на каждом сервере будет свой массив из отданных ему дисков.
С помощью Storage Spaces и SAS свитча можно организовать SAN из JBOD.
Никто этого не отрицает, просто SAN фактически будет создана на серверах, которые уже нельзя будет использовать под кластеризацию — это в случае Windows. Таким образом, чтобы например поднять кластер Hyper-V нужно будет дополнительно к этой JBOD полке и серверам с Srorage Spaces, добавить сервера под кластер. По сути получается, что JBOD полка + сервер(ы) — это СХД.
Да, был не прав. Предположил, что как всегда, MS сделает недоступным совмещение нескольких ролей на одном кластере.
Shared DAS вам нужен, исходя из описания.
Полку можно взять на 24 диска (меньше нет), три сервера прямого подключения поддерживает.
Нюанс — нужны диски с SAS интерфейсом, иначе работать не будет.
Получается не так уж и дёшево, есть ньюансы работы и нет никакого толком функционала, как и пишет Masamasa.
Если сравнивать с самостоятельной СХД — разница в разы, функционал на стороне ОС.
Хотите — поднимите отказоустойчивый кластер приложений прямиком на JBOD, хотите — поднимаете роль отказоустойчивого хранилища и раздаетесь по традиционным каналам.
Уверен, что вы понимаете зачем СХД в мире ентерпрайз существует и почему почти все большие компании приходят к варианту аппаратному, отличий масса, даже не стану это далее комментировать.
Конечно мы понимаем, зачем СХД существует.
СХД — это n серверов с ОС собственной разработки (а то и только частью, отвечающей за управление дисками и интерфейсом пользователя, EMC не стеснялось пользоваться Windows в свое время).
Точно также мы понимаем, что до недавнего времени попросту не существовало сколько-нибудь приемлемого способа сделать отказоустойчивую СХД на доступных компонентах.
Сейчас такая возможность есть и люди, которые сравнивали shared DAS с EMC, 3Par и NetApp, выбирают первый вариант.
На правах рекламы? :)
У каждого своя голова на плечах.
На правах расширения мира ;)
Большие компании раньше и выбирать-то не могли, а сейчас появляется альтернатива.
Расширение мира наступает если набрать на хабре SDS.
А в коментах к СХД про нетап это не расширение мира.

Повторяю ещё раз: я это парировать не стану, потому что это полный оффтоп.
Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC у свитчей компании Cisco серии Nexus.

vPC — разве не тот же Multi-Chassis EtherChannel, просто так названный циской? Смысл же тот же.
Смысл у много чего «тот же», до каких-то пределов. Реализация разная. У Multi-Chassis EtherCannel используется стек свичей, в стеке обычно есть «ведущий» и используется специализированный кабель для соединения стека. У стека собственная схема подключения и т.д. и т.п.

У vPC это не стек и кабеля используются стандартные 10G и их можно наращивать между двумя коммутаторами, нет «ведущего» и т.д. и т.п.

Стек свитчей — это вы наверно про VSS? Так там логически один коммутатор и с точки зрения настройки выглядит, как обычный Port-channel. Поэтому, не посчитал такое включение как Multi-Chassis EtherCannel. =) в общем сложности с формулировками. В моем понимании Multi-Chassis EtherCannel или MLAG или vPC — это одна и та же технология, позволяющая делать один port-channel с незавизимых коммутаторов.
И кстати, у 6500 например стек VSS соединяется обычными 10г линками.
Вот кстати вы напомнили ещё одно отличие — два разных контролплейна у vPC.
Да и ещё кстати, Catalyst 6500 точно уж дешевым решением не назовёшь :)
Понятие мультипасинга применимо только к SAN и IP-SAN (iSCSI), для NFS оно не применимо.

Для SAN (FC, FCoE) мультипасинг может работать между всеми протами всех контроллеров NetApp ( у NetApp один WWNN на все контроллеры и просто разные WWPN у портов), но предпочтительный линк всегда выбирается только один (ALUA).

Для IP-SAN (iSCSI) мультипасинг работает/может между всеми портами одного контроллера, переключение в случае смерти одного контроллера работает аналогично. Но для того, чтобы работал мультипасинг (MPIO) для iSCSI, нужно иметь точно также разные IP и точно также нужно следить, чтобы эти пары IP утилизировали поровну все линки, только LACP в данноом случае не применяется и соответственно вышеописанный механизм здесь не работает.
Меня как раз интересовал MPIO при iSCSI, понятно что распределение нагрузки будет лежать на iSCSI инициаторе.
Переключение в случае выхода из строя контроллера (в отличае от выхода из строя линка) в данном случае будет отрабатывать аналогичным образом, как у NFS — Хост будет ждать (нужно не забыть настроить таймаут на хосте-ах в размере 90 сек) пока умершый контроллер возродится из пепла на втором контроллере. По этому чать про отказоустойчивость на уровне контроллера как для NFS так и для iSCSI одинаково нужно соблюдать.

В случае же FC просто переключается путь через один из портов второго контроллера.
Про контроллер все понятно. Меня больше интересует производительность системы: если у нас настроен iSCSI, а за распределение нагрузки отвечает LACP, то в рамках одного сервера мы прироста производительности практически не получим, и в таком случае, как мне кажется, предпочтительнее использовать MPIO.
Only those users with full accounts are able to leave comments. Log in, please.