Использоваине локальних дисков серверов для общего хранилища

Как создать сервер оптимальной конфигурации.

Модераторы: Trinity admin`s, Free-lance moderator`s

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 20 ноя 2016, 23:09

А не скажите про тиминг сетевых карт? Можно ли увеличить пропускную способность?
Разные источники про разное говорят.

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Umlyaut » 21 ноя 2016, 14:50

Sauron_zombie писал(а):А не скажите про тиминг сетевых карт? Можно ли увеличить пропускную способность?
Разные источники про разное говорят.

Начать с семантики: "тиминг" - это объединение в team/команду, т.е. несколько сетевых линков работают одновременно. Сам термин "тиминг" не в полной мере описывает детали, т.к. таковое объединение возможно на разных сетевых уровнях.

На практике обычно используется два вида тиминга - L2(eth), так же известный как Link Aggregation (LA), и L3(IP), он же multipathing (MP). Строго говоря, всякие технологии "Load Balance" выше L3 тоже можно посчитать за тиминг, но там этот термин практически не используется.

L2-тиминг осуществляется на уровне и с помощью коммутаторов (для отказоустойчивости сюда же прибавляется требование наличия между коммутаторами "честного" стека - через бэкплэйн, с возможностью создавать LA-группу портов между коммутаторами), L3-тиминг от коммутаторов никакой поддержки не требует, будучи настраиваемым на хостах (там, где он предусмотрен, естественно), стекируемость свитчей (в т.ч. для редундантности линков) не обязательна.

В L2-тиминге (LA) в режиме "точка-точка" - между двумя хостами - весь трафик уберётся в один линк группы, т.е. формальная суммарная скорость тим-группы линков НЕ будет работать на увеличение пропускной способности до, скажем, сервера с L2-агрегацией сетевых карт.
Таковое увеличение воспоследует (с рядом условий) лишь в случае трафика через группу в режиме "многие-ко-многим" или в режиме "многие-с-одним".

L3-тиминг (MP) позволяет практически линейно масштабировать трафик через группу интерфейсов даже в режиме "точка-точка".

В качестве иллюстрации к вышесказанному: я использую L2-тиминг на "клиентской" сети Сферы, а L3-тиминг - между хостами Сферы и блочными сетевыми хранилищами. Т.е. ровно там, где это уместно с учётом особенностей того или иного вида тиминга.

Вот вкратце так.

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 21 ноя 2016, 22:27

Umlyaut писал(а): Вот вкратце так.
Ого! Моё почтение и уважение!
Очень подробно и достаточно понятно в теории.
Спасибо!

А вот если взять конкретику.
Если у меня будет, к примеру, самодельное СХД с блочным доступом (iSCSI) на NAS4free.
В нём 4 х 1 Гб LAN, которые подсоединены к гигабитному коммутатору.
Два хоста подсоединяются по 2 х 1 Гб к этому же коммутатору.
Мне надо настроить на хостах этот самый multipathing?
То же надо смтореть и в NAS4free - нечто подобное должно же быть и там.
Да ещё на включать JumboFrame на всех + на коммутаторе самом?

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

!

Сообщение Umlyaut » 21 ноя 2016, 23:49

Sauron_zombie писал(а): А вот если взять конкретику.
Если у меня будет, к примеру, самодельное СХД с блочным доступом (iSCSI) на NAS4free.
В нём 4 х 1 Гб LAN, которые подсоединены к гигабитному коммутатору.
Два хоста подсоединяются по 2 х 1 Гб к этому же коммутатору.
Практически как у меня было (да и есть):

- самодельные СХД с блочным доступам (iscsi) на OpenFiler и CentOS6;
- в них 4 х 1 Гб LAN до гигабитных коммутаторов;
- два хоста Сферы подсоединяются по 6 х 1 Гб к этим же коммутаторам (4 х 1 Гб на iscsi и 2 х 1 Гб на клиентскую сеть (VM`ок) - кстати вторая NIC-тим как раз реализована на L2, через LA-группу);

Sauron_zombie писал(а):Мне надо настроить на хостах этот самый multipathing?
Не знаю, как насчёт "настроить", но мои хосты Сферы имели MP "по умолчанию" - нужно было только немного специфически раздать адреса на iscsi-интерфейсы: они, как я выяснил опытным путём, должны размещаться в разных подсетях класса С - когда они были в одной подсети, то был "перекос" в балансировке трафика, а так трафик "расфасовывается" практически поровну.
Sauron_zombie писал(а):То же надо смтореть и в NAS4free - нечто подобное должно же быть и там.
Вот это вопрос интересный: я на своих хранилках вообще ничего не делал (ну кроме собственно назначения ip-адресов интерфейсов), т.к. MP была заботой хоста-инициатора (Сферы).
А, например, такой широко известный в узких кругах :) "таргет", как StarWind (понятно, там в нём не только iscsi-target, но и куча другого функционала), берёт MP на себя, что даёт возможность использовать с ним МР и "глупым" хостам-инициаторам (которые без своего МР).

Собственно, в первом приближении способность к МР определяется наличием (ну и эффективностью, конечно) у хоста балансировки по типу RR (Round Robin). От этого и нужно отталкиваться.
Но вот как поведёт себя система с включенным МР (сиречь балансировкой RR) на обоих концах - вопрос интригующий: сам я до его выяснения опытным путём пока не добирался. :D
Sauron_zombie писал(а):Да ещё на включать JumboFrame на всех + на коммутаторе самом?
JF - особенно для трафика СХД - вообще "маст хэв".

К слову - я в начале текущего года перевёл сеть СХД на 10Г, но принцип остался тот же (2 x 10Г через два коммутатора (редундантность!) как на хостах-инициаторах, так и на хостах-таргетах).

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: !

Сообщение Sauron_zombie » 23 ноя 2016, 00:00

Umlyaut писал(а): два хоста Сферы подсоединяются по 6 х 1 Гб к этим же коммутаторам (4 х 1 Гб на iscsi и 2 х 1 Гб на клиентскую сеть (VM`ок) - кстати вторая NIC-тим как раз реализована на L2, через LA-группу);
Я тут начудил, конечно. Хостам надо тоже хотя бы 4 х 1 Гб, а не 2.
Umlyaut писал(а): нужно было только немного специфически раздать адреса на iscsi-интерфейсы: они, как я выяснил опытным путём, должны размещаться в разных подсетях класса С - когда они были в одной подсети, то был "перекос" в балансировке трафика, а так трафик "расфасовывается" практически поровну.
Очень полезное замечание!
Umlyaut писал(а): А, например, такой широко известный в узких кругах :) "таргет", как StarWind

Для меня StarWind - это пока что-то из компонентов Alcohol 120% ))))))
Umlyaut писал(а): JF - особенно для трафика СХД - вообще "маст хэв".

Я так и думал )
Umlyaut писал(а): К слову - я в начале текущего года перевёл сеть СХД на 10Г, но принцип остался тот же (2 x 10Г через два коммутатора (редундантность!) как на хостах-инициаторах, так и на хостах-таргетах).
Вах! Это сколько же стоит 2 коммутатора 10 G?

Что касается 10 Гб/с сетевух - посмотрел я на INTEL X540-T2 за 40 т.р. и стало мне очень грустно, т.к. я писал в самом начале что работаю в бюджетной организации и сейчас с финансированием стало непросто. Раньше, может, и выбил бы такие карты, сейчас - не думаю.

А задумки по тимингу, точнее, агрегированию интерфейсов у меня из-за того, что в системной плате 4 сетевухи и есть ещё 2-портовая отдельная PRO/1000 Dual Port.

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 23 ноя 2016, 00:39

Блин, вот тут поглядел - многие сетевухи не поддерживают jumbo frames.
Не пойму - моя на 82571EB умеет или нет?

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

Re: !

Сообщение Umlyaut » 23 ноя 2016, 00:47

Хех! А я тут бродил в ночи по форумам - и на Варерусишюзергруппенфоруме Вам ровно по этой теме и ответил сгоряча. :D
Sauron_zombie писал(а):
Umlyaut писал(а): два хоста Сферы подсоединяются по 6 х 1 Гб к этим же коммутаторам (4 х 1 Гб на iscsi и 2 х 1 Гб на клиентскую сеть (VM`ок) - кстати вторая NIC-тим как раз реализована на L2, через LA-группу);
Я тут начудил, конечно. Хостам надо тоже хотя бы 4 х 1 Гб, а не 2.
Слушайте, ну можно и на двух (по крайней мере поначалу, а там как пойдёт).
У меня тут по iscsi копировалось несколько терабайт vmdk`шек с хранилки на хранилку (быкапил вирт.диски целиком на архивный стор) - дык даже R6 на SATA 7k2 из семи дисков несколько часов держали под 200 мегабайт/сек. непрерывного трансфера. Т.е. под завязку, но пары 1Г в MPIO должно со скрипом, но хватить.
Sauron_zombie писал(а):
Umlyaut писал(а): нужно было только немного специфически раздать адреса на iscsi-интерфейсы: они, как я выяснил опытным путём, должны размещаться в разных подсетях класса С - когда они были в одной подсети, то был "перекос" в балансировке трафика, а так трафик "расфасовывается" практически поровну.
Очень полезное замечание!
Угу. До этого MP был хоть и получше LA-балансировки на тех же линках и свитчах, но ненамного.
А после этого просто как в аптеке.

Кстати, я по следам нашего с Вами общения последних дней по данной теме залез в архивы, освежить память насчёт нижеупомянутого StarWind`a. И в одном из PDF`ов (см.аттач к комментарию) - как раз про евойный MPIO - с удивлением узрел скриншоты, где в явном виде на двух линках видны разные IP-шники как раз в духе этой моей рекомендации. Правда меня смутило, что там не указана маска, а это важно: одно дело, если их адресация, как и моя, идёт по маске 255.255.255.0 - честными разными сетями класса С - и совсем другое, если там какая-нито другая маска (от класса B до подсетей С): тут я уж не возьмусь без экспериментов сказать, что там будет в итоге с балансировкой.

Sauron_zombie писал(а):
Umlyaut писал(а): А, например, такой широко известный в узких кругах :) "таргет", как StarWind

Для меня StarWind - это пока что-то из компонентов Alcohol 120% ))))))


Ну-у-ууу... В принципе это коммерческий софт, да ещё на виндовой платформе.
С другой стороны, у них неплохой набор бесплатных модулей - инициатор, рамдрайв (пользительно для "чистого" тестирования), да даже AoE-инициатор есть. :)
Sauron_zombie писал(а):
Umlyaut писал(а): К слову - я в начале текущего года перевёл сеть СХД на 10Г, но принцип остался тот же (2 x 10Г через два коммутатора (редундантность!) как на хостах-инициаторах, так и на хостах-таргетах).
Вах! Это сколько же стоит 2 коммутатора 10 G?
8-портовые Нетгиры на медь (с одним шаренным гнездом SFP+) стОят очень по-божески - чуть дороже штуки бакинских.
Для SMB-инфрастуктуры то, что доктор прописАл (для разгона, без редундантности, одного хватит для четырёх кузовов с двойными платками, или для восьми с одинарными - пара, соответственно, держит восемь с двойными уже с редундантностью).
Sauron_zombie писал(а):Что касается 10 Гб/с сетевух - посмотрел я на INTEL X540-T2 за 40 т.р. и стало мне очень грустно, т.к. я писал в самом начале что работаю в бюджетной организации и сейчас с финансированием стало непросто. Раньше, может, и выбил бы такие карты, сейчас - не думаю.
Соболезную.
Я сижу на их аналогах от Силикома (ну т.е. чип тот же, просто вендор другой). Драйверы под то же, что и у Интела, ес-сно. Их можно взять в оптовых лавках тысяч за 29 за карту (я брал сразу почти десяток ещё дешевле).

В общем-то Вам можно и на 4 х 1Г замутить, хотя бы сначала как лабу для набивания руки, но и в бой MP бросать не зазорно.

Где-то так. :)

P.S.
Sauron_zombie писал(а):Блин, вот тут поглядел - многие сетевухи не поддерживают jumbo frames.
Не пойму - моя на 82571EB умеет или нет?
Обязана - интеловые давно уже почти все (были у меня проблемы лишь с L-ками под линухом, но я подозреваю косяк в драйвере какой-то).
StarWind_MPIO.pdf
иллюстрация к комментарию :)
(872.01 КБ) 482 скачивания

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: !

Сообщение Sauron_zombie » 23 ноя 2016, 01:10

Umlyaut писал(а):Хех! А я тут бродил в ночи по форумам - и на Варерусишюзергруппенфоруме Вам ровно по этой теме и ответил сгоряча. :D
За это большое спасибо, что отвечаете! :)
Разные мнения присутствуют. Имхо, там более критично (если не сказать ещё как) относятся к самосбору и гигабиту для СХД.
Да и маркетологические изыски, что надо именно это и это покупать, а то не заработает - не по мне.
У меня опыта мало тут, но буду набираться.
Umlyaut писал(а):Слушайте, ну можно и на двух (по крайней мере поначалу, а там как пойдёт).
У меня тут по iscsi копировалось несколько терабайт vmdk`шек с хранилки на хранилку (быкапил вирт.диски целиком на архивный стор) - дык даже R6 на SATA 7k2 из семи дисков несколько часов держали под 200 мегабайт/сек. непрерывного трансфера. Т.е. под завязку, но пары 1Г в MPIO должно со скрипом, но хватить.
Вот мне нужно будет достаточно большие ВМ гонять - около 600 Гб.
Umlyaut писал(а): В общем-то Вам можно и на 4 х 1Г замутить, хотя бы сначала как лабу для набивания руки, но и в бой MP бросать не зазорно.
Да, тестить надо, безусловно!
Тут сегодня с сетью что-то было странное - все диски сетевые отвалились, кругом тормоза, но через небольшое время восстановилось. В логах серваков ничего странного. Наверное коммутаторы затупили от магнитных бурь )))
Стрёмно было, думал, что с контроллером поначалу...

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 23 ноя 2016, 01:30

Вот набрёл на очень сложную для меня статью - Создание надёжного iSCSI-хранилища на Linux - тут вот что говорится:
С протоколом iSCSI бессмысленно использовать Bonding/Etherchannel для ускорения его работы.

Причина проста — при этом используются хэш-функции для распределения пакетов по каналам, поэтому очень сложно подобрать такие IP/MAC адреса, чтобы пакет от адреса IP1 до IP2 шел по однму каналу, а от IP1 до IP3 — по другому.
Тут про то, что Вы мне говорили про разные адреса класса С?
Или тут другое?
Поэтому, для наших целей гораздо лучше подходит использование нескольких путей до LUNа, что мы и будем настраивать.

Каждый LUN будет представлен отдельным iSCSI-таргетом, поэтому каждому таргету были выбраны «общие» кластерные адреса, которые будут подниматься на ноде, обслуживающей этот таргет в данный момент
Вот это кто пояснит? Или тут я лезу в дебри?

P.S. И да простит меня ув.тов. Umlyaut )))

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Umlyaut » 23 ноя 2016, 03:19

Вижу, нам обоим сегодня не спиЦЦа... :)
Sauron_zombie писал(а):Вот набрёл на очень сложную для меня статью - Создание надёжного iSCSI-хранилища на Linux - тут вот что говорится:
С протоколом iSCSI бессмысленно использовать Bonding/Etherchannel для ускорения его работы.

Причина проста — при этом используются хэш-функции для распределения пакетов по каналам, поэтому очень сложно подобрать такие IP/MAC адреса, чтобы пакет от адреса IP1 до IP2 шел по однму каналу, а от IP1 до IP3 — по другому.
Тут про то, что Вы мне говорили про разные адреса класса С?
Или тут другое?
Другое.
В данной статье бондингом/эзерченнелом именуется L2-тиминг с поддержкой коммутатора (etherchannel - это проприетарный цЫсковский аналог LA(CP)). Ну и как я неоднократно ранее упоминал, эффективность его в плане масштабирования пропускной способности тим-группы не ахти (о чём и в статье говорится открытым текстом).

Поэтому, для наших целей гораздо лучше подходит использование нескольких путей до LUNа, что мы и будем настраивать.
А вот это уже, собственно, речь идёт как-раз о L3-тиминге, он же MPIO.
Каждый LUN будет представлен отдельным iSCSI-таргетом, поэтому каждому таргету были выбраны «общие» кластерные адреса, которые будут подниматься на ноде, обслуживающей этот таргет в данный момент
Вот это кто пояснит? Или тут я лезу в дебри?
Это не Вы лезете в дебри, а в этой статье наверчено всего в кучу (не, всё по делу, просто часть не имеет непосредственного отношения к обсуждаемому вопросу - drbd, например, транковые вланы на цЫске и пр.).

Не заморачивайтесь, пожалуйста - и не воспринимайте эту статью как howto`шку: тому, кто понимает, о чём там спич по каждому субвопросу, она не нужна; ну а как методичка-howto`шка для начинающих она никакущая.

"Про адреса класса С" "на пальцах":

- на хосте №1 Сферы включаем iscsi (таргет), создаём отдельный vSwitch под iscsi;
- создаём на этом свитче vkernel`ы iscsi по кол-ву интерфейсов iscsi на хосте - и биндим эти vkernel`ы по одному на каждый pNIC (как это делать, см.мануалы, в частности предельно доступно об этом в книге Михаила Михеева);
- адресуем независимыми С-адресами наши vkernel`ы - допустим, их четыре:

192.168.26.1
192.168.27.1
192.168.28.1
192.168.29.1


Маска каждого - 255.255.255.0

- аналогично на хосте №2 Сферы:

192.168.26.2
192.168.27.2
192.168.28.2
192.168.29.2


На хранилках интерфейсам задаём адреса по тому же принципу:

192.168.26.10
192.168.27.10
192.168.28.10
192.168.29.10


с той же самой маской - 255.255.255.0

Никакого дополнительного шаманства на хранилках по части сети не нужно.

Далее делаем на хранилках нужное число iscsi-таргетов (бест практисы советуют по числу LUN`ов для раздачи - я склонен поддержать эту рекомендацию, т.к. она рабочая, проблем не принесла и аргументированную альтернативу ей лично я сочинить сходу не готов :) ). LUN`ы маппим по одному на таргет.

Ну и, собственно, аллес - на хостах Сферы заводим пути к хранилкам (в Configuration -> Storage Adapter -> software iscsi), хост детектит LUN`ы (в нашем случае - по четырём путям на LUN, через четыре vkernel`а/ip), создаёт на них VMFS-волюмы и вуаля. Да, после появления этих наших новых сторов в списке таковых у хоста надо зайти в свойства каждого стора и в менеджменте путей сменить дефолтную политику путей доступа с Fixed на RoundRobin.

И всё заверте... :D

Это практически исчерпывающая хаутушка по обсуждаемому вопросу отдачи блочных хранилок хосту Сферы с заведомо работающим multipath`ом.

Доброй охоты! :)



P.S.
P.S. И да простит меня ув.тов. Umlyaut )))
За что прощать-то? :)

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 24 ноя 2016, 22:28

Umlyaut писал(а): В данной статье бондингом/эзерченнелом именуется L2-тиминг с поддержкой коммутатора
Спасибо! Теперь ясно!
Umlyaut писал(а): А вот это уже, собственно, речь идёт как-раз о L3-тиминге, он же MPIO.
Как раз то, что мне нужно.
Umlyaut писал(а): Не заморачивайтесь, пожалуйста - и не воспринимайте эту статью как howto`шку: тому, кто понимает, о чём там спич по каждому субвопросу, она не нужна; ну а как методичка-howto`шка для начинающих она никакущая.
Хорошо!
Umlyaut писал(а): "Про адреса класса С" "на пальцах":

Это практически исчерпывающая хаутушка по обсуждаемому вопросу отдачи блочных хранилок хосту Сферы с заведомо работающим multipath`ом.

Доброй охоты! :)
Спасибо! Очень понятно разжевали :)
Umlyaut писал(а): За что прощать-то? :)
За мультипостинг и забивание головы :D

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 24 ноя 2016, 22:37

Тут один винт сдох - он был не в рэйдах и некритичен - вообще не определяется в BIOS'е даже.
А другой винт на рабочем компе стал чудить - винда виснет намертво и после ресета винт тожде не определяется, только если питание вырубить на некоторое время. Посмотрел Викторией - он весь в бэдах, реаллокэйтов - больше 2000 штук.
Короче, к чему я. Подумал я крепко: если вдруг такая хрень, то как я из будущих городушек со самосбором своим буду из таких проблем выбираться?
Пока даже и не знаю.
Правильно говорит бритва Оккама - не плоди сущностей...

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Umlyaut » 25 ноя 2016, 00:40

Sauron_zombie писал(а):Подумал я крепко: если вдруг такая хрень, то как я из будущих городушек со самосбором своим буду из таких проблем выбираться?
Пока даже и не знаю.
Правильно говорит бритва Оккама - не плоди сущностей...
Не нужно размахивать бритвой Оккама попусту - старик Оккам не одобрит. :)

Когда/если винт придёт в негодность, то нет разницы, в чём он это сделает - в самосборном сервере, в брендовом, или в фирменной хранилке: один фиг его нужно будет заменить на годный.
У меня, например, в моём "самосборе", за это отвечают HSD - я последние пару пятилеток без них рейд-массивы в принципе не делаю. Плюс Check Consistency регулярный, плюс переход на использование в основном R6/R60.

Опять же, я завязал с десктопными хардами на первой и частично второй линиях хранилок (боевые и быкапные) - они у меня сейчас остались только на третьей линии (быкапы быкапов и первые архивы). SAS или Ent.SATA насчёт бэдов и прочего побезопаснее будут - к тому же ща буду делать на них дополнительный контроль на уровне физ.секторов (520, 524, 4112 байт), благо мои новые контроллеры умеют T10 PI(DIF).

В общем-то "самосбор" не жупел, не клеймо и не проклятье - если знать, что, как и из чего ты делаешь (ну и иметь прямые руки и опыт). С брендами тоже не всё слава богу - гляньте вон в соответствующие разделы тутошнего форума, как народ плюётся в сторону выкрутасов некоторых брендов. :D

Sauron_zombie
member
Сообщения: 25
Зарегистрирован: 12 авг 2012, 01:03
Откуда: Липецк

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Sauron_zombie » 25 ноя 2016, 16:54

Umlyaut писал(а): Не нужно размахивать бритвой Оккама попусту - старик Оккам не одобрит. :)
Ы :)
Umlyaut писал(а): У меня, например, в моём "самосборе", за это отвечают HSD - я последние пару пятилеток без них рейд-массивы в принципе не делаю. Плюс Check Consistency регулярный, плюс переход на использование в основном R6/R60.
А вот чем Вам нравится RAID6/60 - тем, что объём больше получается? Или тут и отказоустойчивость реальная?
Просто сравнивал сам для себя сколько ребилд RAID1 и RAID5 занимает - жестоко последний время жрёт.
Поэтому, у меня только RAID1/10 - конечно, ровно половина винтов для резерва, но быстро.
Umlyaut писал(а): Опять же, я завязал с десктопными хардами на первой и частично второй линиях хранилок (боевые и быкапные) - они у меня сейчас остались только на третьей линии (быкапы быкапов и первые архивы). SAS или Ent.SATA насчёт бэдов и прочего побезопаснее будут
У меня SAS/SATA как раз энтерпрайзовые. Сдохли внезапно десктопные.
Umlyaut писал(а):к тому же ща буду делать на них дополнительный контроль на уровне физ.секторов (520, 524, 4112 байт), благо мои новые контроллеры умеют T10 PI(DIF).
Тут мне надо поRTFM'иться :oops:
Umlyaut писал(а):С брендами тоже не всё слава богу - гляньте вон в соответствующие разделы тутошнего форума, как народ плюётся в сторону выкрутасов некоторых брендов. :D
Да ужжж...

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

Re: Использоваине локальних дисков серверов для общего храни

Сообщение Umlyaut » 25 ноя 2016, 23:06

Sauron_zombie писал(а):
Umlyaut писал(а): У меня, например, в моём "самосборе", за это отвечают HSD - я последние пару пятилеток без них рейд-массивы в принципе не делаю. Плюс Check Consistency регулярный, плюс переход на использование в основном R6/R60.
А вот чем Вам нравится RAID6/60 - тем, что объём больше получается? Или тут и отказоустойчивость реальная?
Лично мне - за второе, первое так, "бонусом".

С R1 и так всё ясно. Но у него лимитированная ёмкость и скорость. Если нужно нарастить и то, и другое, то придётся строить по-другому:

- у R10 отказоустойчивость в 1 диск "безусловная", а в два и более - "статистическая": выход из строя второго и следующих дисков в деградировавшем массиве сойдёт с рук только при условии, что бедствие постигнет другие сабъюниты, ещё не тронутые.
- R5 и того стрёмнее - один диск и только. R50 несколько смягчает ситуацию, но тут тоже "статистическая" отказоустойчивость для второго диска: "угадай" дизастер по уже деградировавшему к тому моменту сабъюниту-r5, и амба.
- с R6 и R60 уже полегче: первый "держит" вылет двух дисков, ну а второй "статистически" и поболее.
Sauron_zombie писал(а):Просто сравнивал сам для себя сколько ребилд RAID1 и RAID5 занимает - жестоко последний время жрёт. Поэтому, у меня только RAID1/10 - конечно, ровно половина винтов для резерва, но быстро.
Ха! Небось, под нагрузкой рабочей дело было? В этом случае WP у 5-ки увеличивает время ребилда очень ощутимо относительно R1/R10.


По поводу ребилда я вижу так: если контроллер НЕ тормозит при ребилде на вычислении по КС недостающих блоков для записи на spare-носитель, то на таком контроллере ребилд рейд-группы любой размерности (R1, R5, R6 и их 0-производных) на одинаковых хардах будет происходить одинаковое время - т.к. лимитирующим параметром тут будет скорость записи на одиночный (spare) хард в sustained-mode.
Собственно, практика - т.е. время ребилда R10, R6 и R5 (последний делался не для работы, а чисто из любопытства, проверить вышеуказанный тезис) - очень неплохо соответствует ожидавшемуся от этого утверждения результату.
Подчёркнуто повторюсь - без рабочей нагрузки по I/O или с минимумом таковой.

Другое дело, что сами по себе огромные современные диски ребилдятся в деградировавший массив изрядное кол-во часов (та же 4ТБ-шка - около полусуток без нагрузки и сутки с таковой).

Этот момент, кстати, обуславливает допустимость и желательность применения R10 с использованием не хардов, а SSD - и паттерн использования совпадает, и ребилд меньших и быстрых (по сравнению с хардами) носителей отрабатывается шустрее.

Ну и полезная практика смещения приоритетов контроллера от дефолтных фифти-фифти к безусловному приоритету ребилда над I/O.
Да, сетевые диски у юзеров будут тупить, но во-первых сокращение "окна уязвимости" того стОит, как по мне; а во-вторых не факт, что вылет диска и последующий ребилд (про HSD не забываем!) придутся чОтко на 10.00-19.00 и/или на будни - а тогда часть ребилда пройдёт в нерабочий промежуток и завершится ощутимо скорее.

Впрочем, как раз R6 позволяет несколько умерить опасения за массив и дать для I/O несколько "больше кислорода". :)

К слову: есть мнение (не моё, а подсмотренное в Сети), что помимо "статнадёжности" по вылетам дисков R60 ещё может и ребилдиться быстрее - типа, в ребилде участвует не вся дисковая группа, а один сабъюнит.
Вопрос спорный на мой взгляд - если только имеем "экономию" за счёт того, что сики головок при считывании стрипов при ребилде совершаются не всеми дисками рейд-группы, а только членами сабъюнита? Но я не могу ни подтвердить, ни опровергнуть это мнение опытным путём - просто нет таких данных.

Резюмирую: конечно, WP(=6) на R6/60 может несколько пугать относительно такового (=2) на R10, но если увеличение к-ва дисков способно покрыть потребность в Write I/O (дать не ниже нужной по ТЗ), то пуркуа бы и не па?
Взамен "бонусом" идут повышение надёжности (способность пережить вылет больше одного диска), резкое увеличение Read I/O (R6/60 с таким же Write I/O, как и некий R10, будет состоять из бОльшего к-ва дисков - отсюда и прирост по чтению) и доступного объёма.
Sauron_zombie писал(а):
Umlyaut писал(а):к тому же ща буду делать на них дополнительный контроль на уровне физ.секторов (520, 524, 4112 байт), благо мои новые контроллеры умеют T10 PI(DIF).
Тут мне надо поRTFM'иться :oops:
Ну там довольно наглядно всё.

T10 PI(DIF) - это избыточность в аппаратных рейд-массивах на уровне секторов дисков, когда размер сектора не 512, а 520, 528 и т.п. (ну или не 4096, а 4112 и т.п.) за счёт контрольных сумм этого сектора, обрабатываемых рейд-контроллером.

Вкратце вот тут:
https://en.wikipedia.org/wiki/Data_Integrity_Field
http://www.snia.org/sites/default/files ... n_v2.0.pdf
https://habrahabr.ru/post/245085/
http://true-system.blogspot.co.uk/2011/10/sas.html

В качестве "выжимки":

- можно определить наличие поддержки "нестандартных" (а точнее, стандартных с избыточностью) секторов HDD как со стороны рейд-контроллера (спросив его утилитой о пар-ре PI - "supported/unsupported"; наверно, должно быть и в глубине техдокументации на контроллер (не в КвикГайд, ес-сно :) ), так и со стороны дисков (посмотрев спеку);

- при наличии таковой можно задействовать эту "линию обороны" от ошибок носителя, отформатировав диск под нужный формат сектора (520, 528, 4112, etc.) и включив поддержку таковых на рейд-контроллере (пар-р PI=enabled);

- важное нотабене - рейд-контроллер не форматирует сектора дисков на физ.уровне, а лишь умеет работать с таковыми, отличными от стандартных 512/4096... собс-cно, HBA тоже не делает low level format, но через HBA по крайней мере есть возможность это сделать силами сервисных утилит от вендора.
Впрочем, для этой цели сойдёт и sg_format (см.выше ссылку на sg.danny.cz).

. . .

Собственно, эта тема краем касается другой - того недоумения, которое охватывает нашего брата, когда они цепляют к стандартным массовым рейд-контроллерам (например, широко распространённым 9260/61 и пр. на этом чипе) какие-нито "фирменные" диски (например, распроданный по дешёвке нулёвый дисковый ЗиП от брендовых хранилок, у которого случился EOL и т.п.), а они "не видятся" контроллером, не желающим иметь с ними дело (скажем, из биоса контроллера они видятся как "Unsupported GOOD" или вообще как "Unknown drive/device").

А всё дело в том, что "фирменные" диски изначально запросто могут иметь заводскую разметку секторов физ.уровня под
"нестандартный" формат. Совсем недавно мне пришлось излагать это всё одному коллеге с фуджиками SAS с сектором в 2048b. После чего он их форматнул через HBA (точнее, через рейд-контроллер, временно перешитый из IR в IT :) - ну не было у него HBA) как раз sg_format`ом в 512b - и всё заверте... :D

Ответить

Вернуться в «Серверы - Конфигурирование»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 28 гостей