Comments 44
А почему hostname у NetApp'а «san*»? Ведь NFS это не SAN, а NAS.
Я задам вопрос немного не по теме.
Я с СХД плохо знаком. Информацию просто надо вырывать по кускам у разных людей.
Есть ли просто тупые корзины в которе можно было бы поставить обычные sata, и по SFF соединить с рядом машин? например с тремя.
Я с СХД плохо знаком. Информацию просто надо вырывать по кускам у разных людей.
Есть ли просто тупые корзины в которе можно было бы поставить обычные sata, и по SFF соединить с рядом машин? например с тремя.
В народе так и называют корзина для дисков.
Наверно вы про JBOD.
Наверно вы про JBOD.
Ну все что я встречал, это расширение для других корзин.
Хотелось бы на текущий момент взять 1u корзину с 4 дисками sata и подключить к серверам. Точка отказа будет корзина.
Бюджет небольшой. Я сам работал с hp 2000p, честно говоря не впечетлен был от устройства за такие деньги.
Хотелось бы на текущий момент взять 1u корзину с 4 дисками sata и подключить к серверам. Точка отказа будет корзина.
Бюджет небольшой. Я сам работал с hp 2000p, честно говоря не впечетлен был от устройства за такие деньги.
Если вам нужна отказоустойчивость и плюс к этом вам нужно разделять ресурсы дисков между хостами, значит вам нужна СХД.
Бывают СХД которые могут подключать несколько серверов по SAS. К примеру NetApp E-серия.
Бывают СХД которые могут подключать несколько серверов по SAS. К примеру NetApp E-серия.
Если проблема бюджете на столько велика, то вам однозначто прийдётся крутить что-то на коленке.
К примеру можно взять два сервера настроить кластеризацию или репликацию между ними. Потом настроить доступ к этим серверам, к примеру по iSCSI, NFS или FC (нужно купить HBA адаптеры).
Но это получится та же, но самодельная СХД.
К примеру можно взять два сервера настроить кластеризацию или репликацию между ними. Потом настроить доступ к этим серверам, к примеру по iSCSI, NFS или FC (нужно купить HBA адаптеры).
Но это получится та же, но самодельная СХД.
Но зачем тогда их запихивать в одну корзину не пойму, если нужно эти диски раздавать нескольким хостам не пойму.
Стандартная парадигма такова:
Либо вам нужно большое количество дисков для одного контроллера, и здесь просто используются корзины, далее объединение дисков в рейд осуществляется на программном или аппаратном уровне.
Либо вам нужно собрать все диски в одно место объединить их как-то (тут уже тупая железяке на катит), а потом раздавать не диски, а ресурсы на этих дисках нескольким серверам. Это делает СХД.
Стандартная парадигма такова:
Либо вам нужно большое количество дисков для одного контроллера, и здесь просто используются корзины, далее объединение дисков в рейд осуществляется на программном или аппаратном уровне.
Либо вам нужно собрать все диски в одно место объединить их как-то (тут уже тупая железяке на катит), а потом раздавать не диски, а ресурсы на этих дисках нескольким серверам. Это делает СХД.
ЗЫ.
SFF — это Small form factor а не тип подключения. Вы наверное про SAS или SFP.
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
мне интересно, что бы машины видели один массив жестких дисков. Грубо говоря, если мы СХД подключем по 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
Поискал тут на хабре. Примерно надо наверно типа DAS получается.
habrahabr.ru/company/etegro/blog/215333/
habrahabr.ru/company/etegro/blog/215333/
DAS это прямое подключение к одному серверу. Судя по вашему запросу вам подойдёт вот это www.depo.ru/config_depo_c1901_i140679_m2.aspx
ну вот пример. www.etegro.ru/configurator/storage/jbod/js300g3
я так понимаю примерно то что мне надо. Полка, отдает по SAS на сервер.
Технология shared DAS. Только вот такой объем дисков не нужен.
я так понимаю примерно то что мне надо. Полка, отдает по SAS на сервер.
Технология shared DAS. Только вот такой объем дисков не нужен.
На том же сайте, что я писал выше, есть JBODы от 12 дисков, SAS свитч в конфигураторе для организации shared DAS тоже имеется.
Щас меня побьют за рекламу я чую… xD
Щас меня побьют за рекламу я чую… xD
Я посмотрю. Вообще как правильно называется то что я хочу? Я бы сам попробовал поискать.
Просто когда мы задумывались и была возможность в теории купить схд, сильно смотрели в сторону ibm storwize. После HP 2000 функционал был сказка.
Сейчас к сожелению возможности покупки минимальны, а организовать кластер с миграцией хочется. NAS не подходят по производительности.
Ну а sas, так как остались платы.
Просто когда мы задумывались и была возможность в теории купить схд, сильно смотрели в сторону ibm storwize. После HP 2000 функционал был сказка.
Сейчас к сожелению возможности покупки минимальны, а организовать кластер с миграцией хочется. NAS не подходят по производительности.
Ну а sas, так как остались платы.
Если правильно и дорого, то SAN (Netapp e-серия например), если дёшево и хитро JBOD + SAS свитч… со вторым вариантом на практике не сталкивался, но наверняка там есть какие то проблемы, всегда сопровождающие решения из категории дёшево и хитро :)
Не забывайте ещё и про то, что купить можно за дёшиво, а потом за дорого сопровождать и восстанавливать. А «дорого», это не всегда деньги, иногда это «время».
NAS, SAN и DAS это типы подключений, а не типы СХД. Многие СХД умеют одновременно иметь подключения, к примеру NetApp E-серия может быть как по SAN так и по DAS. FAS серия может быть как по SAN так и по NAS одновременно
Некоторые СХД с подключением по NAS дают миллионы IOps и десятком мс задержки на случайных операция чтения-записи.
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 полка + сервер(ы) — это СХД.
Почему нельзя совмещать Storage Spaces и Hyper-v роли?
www.aidanfinn.com/?p=15243
blogs.msdn.com/b/clustering/archive/2012/06/02/10314262.aspx
www.aidanfinn.com/?p=15243
blogs.msdn.com/b/clustering/archive/2012/06/02/10314262.aspx
Shared DAS вам нужен, исходя из описания.
Полку можно взять на 24 диска (меньше нет), три сервера прямого подключения поддерживает.
Нюанс — нужны диски с SAS интерфейсом, иначе работать не будет.
Полку можно взять на 24 диска (меньше нет), три сервера прямого подключения поддерживает.
Нюанс — нужны диски с SAS интерфейсом, иначе работать не будет.
Если сравнивать с самостоятельной СХД — разница в разы, функционал на стороне ОС.
Хотите — поднимите отказоустойчивый кластер приложений прямиком на JBOD, хотите — поднимаете роль отказоустойчивого хранилища и раздаетесь по традиционным каналам.
Хотите — поднимите отказоустойчивый кластер приложений прямиком на JBOD, хотите — поднимаете роль отказоустойчивого хранилища и раздаетесь по традиционным каналам.
Уверен, что вы понимаете зачем СХД в мире ентерпрайз существует и почему почти все большие компании приходят к варианту аппаратному, отличий масса, даже не стану это далее комментировать.
Конечно мы понимаем, зачем СХД существует.
СХД — это n серверов с ОС собственной разработки (а то и только частью, отвечающей за управление дисками и интерфейсом пользователя, EMC не стеснялось пользоваться Windows в свое время).
Точно также мы понимаем, что до недавнего времени попросту не существовало сколько-нибудь приемлемого способа сделать отказоустойчивую СХД на доступных компонентах.
Сейчас такая возможность есть и люди, которые сравнивали shared DAS с EMC, 3Par и NetApp, выбирают первый вариант.
СХД — это n серверов с ОС собственной разработки (а то и только частью, отвечающей за управление дисками и интерфейсом пользователя, EMC не стеснялось пользоваться Windows в свое время).
Точно также мы понимаем, что до недавнего времени попросту не существовало сколько-нибудь приемлемого способа сделать отказоустойчивую СХД на доступных компонентах.
Сейчас такая возможность есть и люди, которые сравнивали shared DAS с EMC, 3Par и NetApp, выбирают первый вариант.
Т.е. вполне логично использовать схему, где два свича в стеке используют Multi-chassis EtherChannel агрегируя линки идущие от каждого контроллера в каждый свитч для получения как отказоустойчивости так и утилизации пропускной способности всех этих линков. Такая-себе архитектура по образу и подобию FlexPod Express, но без модно-дорогой фичи vPC у свитчей компании Cisco серии Nexus.
vPC — разве не тот же Multi-Chassis EtherChannel, просто так названный циской? Смысл же тот же.
Смысл у много чего «тот же», до каких-то пределов. Реализация разная. У Multi-Chassis EtherCannel используется стек свичей, в стеке обычно есть «ведущий» и используется специализированный кабель для соединения стека. У стека собственная схема подключения и т.д. и т.п.
У vPC это не стек и кабеля используются стандартные 10G и их можно наращивать между двумя коммутаторами, нет «ведущего» и т.д. и т.п.
У vPC это не стек и кабеля используются стандартные 10G и их можно наращивать между двумя коммутаторами, нет «ведущего» и т.д. и т.п.
Стек свитчей — это вы наверно про VSS? Так там логически один коммутатор и с точки зрения настройки выглядит, как обычный Port-channel. Поэтому, не посчитал такое включение как Multi-Chassis EtherCannel. =) в общем сложности с формулировками. В моем понимании Multi-Chassis EtherCannel или MLAG или vPC — это одна и та же технология, позволяющая делать один port-channel с незавизимых коммутаторов.
И кстати, у 6500 например стек VSS соединяется обычными 10г линками.
И кстати, у 6500 например стек VSS соединяется обычными 10г линками.
А multipath для поставленных целей нельзя использовать?
Понятие мультипасинга применимо только к SAN и IP-SAN (iSCSI), для NFS оно не применимо.
Для SAN (FC, FCoE) мультипасинг может работать между всеми протами всех контроллеров NetApp ( у NetApp один WWNN на все контроллеры и просто разные WWPN у портов), но предпочтительный линк всегда выбирается только один (ALUA).
Для IP-SAN (iSCSI) мультипасинг работает/может между всеми портами одного контроллера, переключение в случае смерти одного контроллера работает аналогично. Но для того, чтобы работал мультипасинг (MPIO) для iSCSI, нужно иметь точно также разные IP и точно также нужно следить, чтобы эти пары IP утилизировали поровну все линки, только LACP в данноом случае не применяется и соответственно вышеописанный механизм здесь не работает.
Для SAN (FC, FCoE) мультипасинг может работать между всеми протами всех контроллеров NetApp ( у NetApp один WWNN на все контроллеры и просто разные WWPN у портов), но предпочтительный линк всегда выбирается только один (ALUA).
Для IP-SAN (iSCSI) мультипасинг работает/может между всеми портами одного контроллера, переключение в случае смерти одного контроллера работает аналогично. Но для того, чтобы работал мультипасинг (MPIO) для iSCSI, нужно иметь точно также разные IP и точно также нужно следить, чтобы эти пары IP утилизировали поровну все линки, только LACP в данноом случае не применяется и соответственно вышеописанный механизм здесь не работает.
Меня как раз интересовал MPIO при iSCSI, понятно что распределение нагрузки будет лежать на iSCSI инициаторе.
Переключение в случае выхода из строя контроллера (в отличае от выхода из строя линка) в данном случае будет отрабатывать аналогичным образом, как у NFS — Хост будет ждать (нужно не забыть настроить таймаут на хосте-ах в размере 90 сек) пока умершый контроллер возродится из пепла на втором контроллере. По этому чать про отказоустойчивость на уровне контроллера как для NFS так и для iSCSI одинаково нужно соблюдать.
В случае же FC просто переключается путь через один из портов второго контроллера.
В случае же FC просто переключается путь через один из портов второго контроллера.
Про контроллер все понятно. Меня больше интересует производительность системы: если у нас настроен iSCSI, а за распределение нагрузки отвечает LACP, то в рамках одного сервера мы прироста производительности практически не получим, и в таком случае, как мне кажется, предпочтительнее использовать MPIO.
iSCSI это отдельная песня. Вот здесь гляньте сравнения комбинаций конфигураций iSCSI по производительности на NetApp.
Обновленная вресия этой статьи про LACP, с обновленным алгоритмом на С++.
Sign up to leave a comment.
Агрегация каналов и балансировка трафика по IP для СХД