Вдогонку за кроликом или fiber-channel, linux и много-много google

Эта статья описывает муки настройки fiber channel target поверх Centos.

Коллегам, хорошо разбирающимся в линукс, можно читать в качестве анекдота 🙂

  1. Несколько лет назад мы делали резервные копии на VTL-систему HP VLS 6500. Это сервер DL360 G4p с PCI-X контроллером SA6404, к которому подключены по SCSI 4 дисковые полки MSA20 (с обычными SATA-винтами внутри). Все было хорошо, пока не сдохла батарейка на модуле ввода вывода одной полки. После этого в произвольное время (когда запись попадала на эту полку) скорость записи падала до нулевых значений. Долой разврат, сказали мы и закопали стюардессу выключили железяку 🙂
  2. “Вирус” написал свою статью про FC-хранилище на Gentoo. Я прочитал – и ничего не понял, хотя статья реально неплохая!
  3. Прошло несколько лет и нам снова стало некуда бэкапить 🙂
    Я вспомнил его слова, прочитал статью и снова ничего не понял, но на всякий случай выкопал стюардессу.
  4. Гугление “Linux fc target” привело меня на русскоязычный гайд по настройке дискового хранилища на Centos7&SCST. Кстати, после 5-7 по счету прочтения гайда и примерно 7й установки CentOS7 я пришел к выводу, что гайд содержит абсолютно всю требуемую информацию для поднятия SCST в формате “далее-далее-готово”. 🙂
  5. В гайде подразумевалось, что прокси вам не нужен. Как это не нужен? – воскликнул я 🙂
  6. Оффтоп: если бы я знал, из скольких пунктов будет состоять эта статья, и сколько времени я убью на получение работоспособного варианта – я бы не начинал свои изыскания 🙂
  7. Немного погуглил и настроил работу yum через прокси. Потом еще погуглил и научился делать системную переменную для прокси. Встал на грабли с регистрозависимыми строками в линукс. Потом еще немного – и научился авторизовываться на прокси доменным пользователем со сложным паролем, содержащим спецсимволы (\ и @). Научил линукс проксировать git. Потом svn – и тут меня опечалил тот факт, что svn использует ssl-туннель на нестандартном порту. Так как мы работаем через TMG, то для поддержки SSL на нестандартном порту необходимо удалить аппендицит через толстую кишку в тайном месте добавить этот порт и перезапустить службы TMG с прерыванием доступа к сети интернет. До вечера ждать было неохота… Короче, я плюнул и попросил у сетевиков прямой доступ к сети интернет. Это реально оказалось проще, не повторяйте мою ошибку с прокси 🙂
  8. Итак, у нас есть Centos7 и SCST, установленные на DL360 G4P. Тут я нагуглил, что SCST – это выпиленный из ядра функционал, и вместо него есть штатная штуковина – LIO. Душа моя запела, я опять переустановил CentOS и начал впиливать LIO. С горем пополам (и несколько дней спустя) я понял, что от меня требуется и скомпилировал ядро нужным образом. Но тут DMESG сказал, что мой адаптер не поддерживает работу в режиме target. “Пичаль-пичаль” сказал я, попробовал подсунуть ему другие драйвера из каталога SCST. Еще раз скомпилировал – при старте драйверов все стало фиолетово (PSOD).
  9. В общем, дальнейшие игры показали, что 4*2Гбит/с QLogic QLA2340 маленько не поддерживается в LIO.
  10. Очередная переустановка, и я начал думать, как же мне организовать мое дисковое пространство. Посовещавшись с MrAloof, я решил сделать RAID6 из 46 SATA500 (средствами MD) и оставить два диска в хотспаре. Прошло еще несколько дней – массив запилился – пришла пора тестов 🙂
  11. Установил cciss-драйвер для HP Smart Array 6400 – он отсутствовал в Centos 7. Заодно впилил Array Control Utility и ее CLI-версию, и System Management Homepage. Глючит и иногда подвисает ACU через веб 🙁
    Впрочем, SSA (Storage Admin) вообще не видит SA 6400.
  12. Попутно были погуглены гайды по оптимизации, в результате которых битмап я вынес на локальные диски сервера, увеличил размер блока страйп кэш и увеличил параметр опережающего чтения (read ahead). Размер страйпа был оставлен по умолчанию – в 512кб, хотя есть заметки, считающие что размер блока лучше сделать 64кб или 128кб. Размер блока кэша сбрасывается после перезагрузки.
  13. Массив был презентован серверу бэкапов как дисковое устройство, отформатирован и добавлены в MPIO все видимые пути (4*2Гбит). Запустил бэкап – скорость записи до 100МБ/с. “Не фонтан”, зато они были равномерно раскиданы по всем четырем линкам (Round Robin работает, ура-ура-ура) 🙂
  14. Из консоли сервера понять я ничего не смог, пришлось попросить о помощи коллегу линуксоида. Тот сказал, что при записи процессор загружен ровно на 50%. А процессор у DL360 G4P – это два Xeon 3000 с включенным гипертредингом. Мы с коллегой предположили, что Зионы лохматят бабушку при попытке записи и не справляются с записью (не угадали).
  15. На смену был взят другой сервер – DL360 G5 с двумя четырехьядерными зионами и 20 гигабайтами оперативной памяти и тут понеслась эпопея по новой :))
  16. Установка на него CentOS7 сразу не пошла, так как это слишком старый сервер и его рейд-контроллер больше не поддерживается. Вы же помните пункт №11 – про выпиленный из Centos7 драйвер cciss. В принципе, гайды по его “впиливанию” гуглятся, но я решил так не извращаться и взять чуть более старый Centos – 6.7. Centos 6.7 на Dl360 G5 встал влет! 🙂
  17. В DL360 G4p было два порта PCI-X, в которые замечательно встали QLA2340 и SA6400. А вот в DL360 G5 был один PCI и один PCI-E. К сожалению, под рукой у меня не нашлось железячки, которая бы позволила воткнуть мои платы ввода-вывода в этот сервер. Поэтому, вместо QLA2340 был подключен 2*4Gbit адаптер Emulex LPe11000. Реально – я не ожидал подвоха, однако…
  18. Достаточно быстро оказалось, что LIO не поддерживает Emulex. Печально, возьмем SCST. Оказывается, в состав SCST драйвера emulex тоже давно не входят, их надо отдельно брать с сайта производителя.
  19. Где-то тут Дима написал на форуме “Месье знает толк в извращениях“. Так и хотелось воскликнуть “да что ты знаешь о мании величия, ничтожный человечишка!!!!!111” 🙂
  20. На сайте производителя для LPe11000 драйверов не было. В конце концов, я выкачал OneCore Storage Driver, закинул его через WinSCP, скомпилировал в соответствии с гайдом SCST и драйвер и хоппа – не работает. В SCST таргет появился, однако сервер бэкапов так и не увидел хранилку. В release notes к драйверу, кстати, было сказано, что он поддерживает LPe15000 и LPe16000.
  21. Не судьба, подумал я и начал искать PCI-E адаптеры в закромах родины и серверах. Сплошь и рядом были Emulex, но вдруг (совсем внезапно) нашелся однопортовый QLE2460. Урра, тестируем дальше 🙂
  22. Однако ж, это не QLE2460, а HPAE311A. Вроде как те же яйца, однако прошивка с сайта QLogic не подходит 🙂
  23. Воткнул, переустановил, пошел развлекаться дальше. LIO по гайду не завелся, я решил снова ставить SCST :)))
  24. К моему горькому сожалению SCST тоже не завелся и вот тут я подвис 🙂
  25. Гугление по ошибке /bin/sh: bc : command not found и make[1]: *** [kernel/timeconst.h] Error 127 показало, что у меня не установлен модуль bc. Делаем yum install bc -y
  26. Заодно коллеги из сообщества redhat подсказали, что режима Target в ядрах RedHat/Centos 7.x нет специально и желающим его включить можно рассмотреть альтернативы (Gentoo/Fedora). Так как я уже немного привык к интерфейсу Centos, то я решил не переучиваться и дальше лохматить Centos 6.7.
  27. “ERROR: modinfo: could not find module scsi_tgt”. Решение – попробовать указать через симлинк каталог  с ядром. ln -s /root/linux-3.18.25 /usr/src/linux. Не помогло 🙁
  28. Очередные переустановки и дотошное следование гайду из первых строк принесло свои плоды – SCST завелся (только служба по другому прописывается в автозапуск).
  29. После этого 20ТБ были отформатированы в XFS, создан файлик и презентован через SCST FileIO.
  30. Скорость была не фонтан – в пике 150МБ/с. Презентовал этот же диск через Veeam Linux Rep – скорость до 110МБ/с (и чего я напрягался) :)))

В общем, это было увлекательное, но очень долгое путешествие.

15 thoughts on “Вдогонку за кроликом или fiber-channel, linux и много-много google”

  1. А CentOS зачем переставлять???
    И прошу прощения, но какая может быть скорость на обычных дисках.
    Ее можно сразу было рассчитать и не мучаться.
    Вопрос про FC не задаю, понимаю, что было железо 🙂

    И почему нельзя было впилить драйвера от RedHat?
    Для него всегда все есть нормального качества, хоть и не OpenSource.

  2. На 6-м пункте, на всякий случай, посмотрел – на сколько пунктов статья…

  3. 2Philzy: а фиг его знает. Так как я с линуксом на вы, то особо не разбирался. Надо все очистить, переставляем ))
    А один раз я так зачетно удалил LVM-тома, что потом вообще установить Centos не смог :)))

    Скорость… Ну я надеялся, что Raid6 на 40+ SATA500 все же выжмет 300-400МБ/с скорости. В принципе, с “здоровых” MSA-20 там и получаются нормальные скорости в 100+МБ/с. А вот “дохленькая” выдает без кэша дисков порядка 10-15МБ/с…

    Почему не RH? А фиг его знает.
    Насколько я понял апологета RH, драйвера-то впилить можно, но вот target-режима в qLogic в них нет, как и его поддержки в ядре. А если компилируешь ядро, то принципиальной разницы вроде как нет между дистрибутивами.
    2Omnimod: Ага 🙁
    Вся эта эпопея затянулась на 3 месяца (с февраля по апрель).

  4. Нету

    2Phylzy: FC я решил использовать, так как по гигабиту много не набэкапишь.

  5. Погодите, но можно посчитать сколько вам отдадут диски и понять какая ширина канала может быть утилизирована.
    Ну есть же арифметика и она говорит, чтобы наполнить 4Гб на обычных sata дисках вам надо 4000/40 (реальная скорость sata диска ) =100 дисков минимум в RAID10, где есть сложение скоростей (очень условное).
    Про IOPS я скромно умолчу, тут они не важны.
    И имея половину дисков можно было сразу понять, что более теоретических 200 Мб/с не выкрутить.
    Плюс Round/Robin не суммирует скорость в канале, а всего лишь определяет пути связности, как и LACP. И на основании этого не мучаться с подобным решением.
    Ну или на крайний случай использовать – http://www.quadstor.com
    Оно вполне рабочее, со своим стеком iSCSI, который весьма неплох.

  6. 2Philzy: Пагады пагады 🙂
    А ты не путаешь гигабиты (Гб) и гигабайты (ГБ)?
    FC4 – это 4Гбит/с или примерно 500МБ/с (400 по другим источникам).
    И 40МБ на один SATA-диск в шестом рейде дадут (в теории):
    46 (количество)*40МБ / 6 (рейд-6 пенальти) = 306МБ/с.
    Причем эта формула справедлива для случайного доступа – в последовательном в действие вступает еще и кэш.

    Ну и Round Robin от SCST мне реально понравился: на 4*2Гбит/с он грузил все четыре канала у карточки (по обеим фабрикам) на 20%. То есть на источники были нагружены линки в обе фабрики, причем поровну.

    Вокруг iSCSI и его инкарнаций я решил не крутиться, так как у меня сеть 1Гб. Иметь жесткое ограничение в 110МБ/с и загруженный на половину линк сервера (там 2*1Гб) – не самое лучшее решение. Особенно, если винты в теории способны выдать на запись побольше 100МБ/с.

  7. philzy wrote:

    >>Плюс Round/Robin не суммирует скорость в канале, а всего лишь определяет пути связности, как и LACP. И на основании этого не мучаться с подобным решением.

    Упоминание в одной фразе RR и LACP как бы намекает, что речь может вестись о iscsi. 🙂
    Тогда мне процитированное утверждение представляется небесспорным: RR именно что раскидывает более-менее поровну нагрузку между несколькими линками (собственно, LA(CP) призван делать то же самое, просто иным образом – и из-за ограничений у него это, на мой взгляд, получается похуже: сужу по личному опыту).
    “Связность” тут вообще дело иное.

    Я понимаю, что данная проблема ощутимо контекстнозависима – лично я этот вопрос познал в процессе работы со Сферой. Вначале (с 4.0) я чисто по привычке делал между хостами Сферы и хранилками транки LA(CP) на паре, а потом и на четырёх гигабитных линках.
    Да, редундантность соблюдалась (пока был жив хоть один линк АКА один свитч из стека, по которому был размазан LA(CP)-транк), а вот загрузка их была неравномерной. Впрочем, на R10 из SATA 7k2 дисков это было нектуально.

    Всё поменялось, когда я стал переводить хранилки на бОльшее число шпинделей, причём уже SAS, причём часть из них 10k. Бенчмарки новых “быстрых” LUN`ов по сети стали проигрывать бенчмаркам их же, но локальным. Как раз в это время я перешёл с 4-й Сферы на 5-ю, в которой несколько изменилась iscsi-подсистема. Решил попробовать “рассыпать” LA(CP)-транки на свитчах, заменив их на iscsi-MP. После некоторого “недокументированного” тюнинга хостов и хранилок (у меня пока в ходу OF – раньше 2.3, теперь 2.99 – но готовлюсь к переходу на CentOS 7 с SCST) MP – с RR со стороны хостов Сферы – просто залетал: и бенчмарк, и Storage vMotion по 4x1Gbit прогружал все линки на максимум (~100-110MB/s) и самое главное, РАВНОМЕРНО!
    Да, JF на всей цепочке маст хэв (впрочем, я давным-давно об этом провещился на vm4.ru у Михаила Михеева :))!

    Спустя некоторое время бОльшая часть моих шпинделей на хранилках стала SAS 10k, а так же появилось ssd-кеширование некоторых LUN силами рейд-контроллеров (CacheCade LSI) и несколько LUN из SSD. Под это дело я перевёл сеть iscsi на отдельную ethernet-инфраструктуру 10Gbit (холст, масло… тьфу! …медь, пара недорогих 8-портовых нетгиров, пара SFP от них на соседнюю площадку).
    Что могу сказать, коллеги – лепота! Помимо уменьшения латентности резко возросли скоростные возможности – тот же SvMotion с SSD на SSD на паре 10G-линков выдавал под 900MB/s, причём расфасованных поровну (~450MB/s на каждый линк). Т.е. RR при MP на iscsi Сферы работает близко к идеалу – и это при дефолтных порогах 1000 iops (хочу попробовать переключить на 1 iops и посмотреть, что будет). Быкапы, соответственно, тоже летают.

    Это я всё не в плане похвальбы рассказал, а в качестве иллюстрации, что “серебряной пули” “вообще и всегда” не бывает, но в своей нише добиться практически линейного масштабирования трафика на нескольких гигабитных (и не только) линках можно.

    Вот как-то так.

  8. Я у себя грешу на “погибший” кэш модуля ввода вывода одной из полок.
    Потому что до того, как я начал делать общий программный рейд, я тестировал с помощью DD запись на аппаратные Raid5 из 6 sata дисков.
    На здоровой дисковой полке запись была в районе 100МБ/с. На дисковой полке “курильщика” – 15МБ/с (с отключенным кэшем дисков). С включенным – порядка 30-40МБ/с.
    Соответственно, у меня был выбор: либо 20ТБ, но медленно, либо 15ТБ – но быстро.
    Так как данный репозиторий планировался под бэкапы Exchange от Veeam, занимающие по 7ТБ фул бэкапов, то 15ТБ мне подходили только в формате Forever Incremental.
    А я с ним уже натерпелся – процесс слияния инкрементального бэкапа идет 8 часов. Ну нафиг.

  9. Ведь таки не послушал ты меня. Раз вся свистопляска началась из-за батарейки, может просто стоило её заменить? 🙂

  10. Угу.
    Мы один раз попробовали – не помогло.
    А нехватка бабла по бюджету не позволяет развлекаться, заказывая все новое и новое железо на замену этому.
    Это я от избытка свободного времени решил выкопать стюардессу.

  11. А что не так с Forever Incremental. ?
    Я тут решил вплотную veeam-ом заняться

  12. С точки зрения используемого места все зашибись: на диске хранится одна полная копия и указанное количество инкрементов.
    Удаляемый (самый первый инкремент) внедряется в полную копию.
    Также я обнаружил два минуса:
    1) полный бэкап имеет свойство разрастаться. Созданный с нуля полный бэкап весит на 50% меньше места, чем имеющийся полный бэкап (проживший полгода и массовые миграции ящиков туда-сюда);
    2) имеется адовая нагрузка на случайную запись при внедрении. У меня 200ГБ инкремента внедрялись в полный бэкап примерно 7-8 часов (правда, я затруднюсь уточнить – на каких именно дисках он лежал – предположительно на смеси SAS+SATA).

  13. Кстати, забыл упомянуть: SCST поддерживает ALUA.
    То есть вы можете сделать кластер из двух систем и презентовать его по FC.
    Получится вполне неплохая альтернатива любому двухконтроллерному СХД entry-level.

Leave a Reply

Your email address will not be published. Required fields are marked *