Комментарии 37
Спасибо за статью.
Вот еще один очень хороший и компактный документ.
Вот еще один очень хороший и компактный документ.
Не буду разводить холивар на общую тему кит vs. слон какой протокол для чего лучше, но кое-что хотелось бы уточнить. Следующая фраза в большинстве реальных применений неверна:
Чистый LACP будет в такой конфигурации, в общем виде, оперировать отдельными серверами, т.е. трафик одного сервера (точнее, одной P2P-пары серверов) не будет делиться между портами.
В такой ситуации трафик нужно делить уровнем выше, при помощи соответствующих стандартов multipath, например, в случае Microsoft SMB3 для хранения образов Hyper-V, после минимальных настроек будет работать SMB3 Multichannel, который действительно разделит трафик между портами, причём кроме поддержки Jumbo Frames от коммутатора ничего не требуется.
Ещё стоит заострить внимание на вопросе обновления программного обеспечения. От правила «каменного века» IT-технологий «работает — не трогай» уже пора отказаться по соображениям безопасности. Вот тут во весь рост встаёт вопрос сдвоенных контроллеров, кластеризации самой системы хранения для обеспечения обновления без downtime.
SAS-системы в таком случае выигрывают — регулярно обновлять там, практически, нечего, а сдвоенная шина предусмотрена самим стандартом SAS, и, практически, «бесплатна».
В то же время системы более высокоуровневого хранения имеют полноценную операционную систему, а её нужно регулярно обновлять. Регулярное же обновление означает либо регулярные (плановые) отключения (что может быть не страшно, например, для небольшой организации, работающей строго до 6 вечера), либо практическое удвоение (а, возможно, и многократное увеличение) бюджета при покупке «двухголовых» систем хранения с возможностью обновляться «на лету».
В итоге, за фронтоном высокоуровневой SAN-системы может прятаться всё тот же SAS DAS на два сервера.
Ну и, конечно, в статье ни слова о SSD. Время, когда огромными массивами дисков компенсировали их ужасающий seek time, к счастью, прошли. Hot tier на SSD полностью переворачивает подход к созданию дисковых систем хранения. И тут у «голого» SAS проблемы: SSD-накопители с интерфейсом SAS стоят (на мой взгляд, абсолютно неоправданно) как самолёт, причём не в сравнении с накопителями домашнего класса, которые в качестве hot tier продержатся месяц, а с вполне серверными SATA-решениями. Interposers для превращения SATA SSD-накопителя в SAS существуют, но продаются практически из-под полы, уж не знаю, из-за картельного ли сговора, или очередные патенты запрещают.
Стоит также напомнить про гиперконвергентные системы. Сложно сказать, заменят ли они традиционные СХД, но в «конспекте админа» хотя-бы пометку о их существовании сделать стоит.
Если остро стоит вопрос экономии бюджета и сетевое оборудование 10 Гб в него не вписывается, то можно объединять гигабитные порты при помощи агрегации каналов (LACP). Так можно получить недорогие 2-4 Гб/с линки.
Чистый LACP будет в такой конфигурации, в общем виде, оперировать отдельными серверами, т.е. трафик одного сервера (точнее, одной P2P-пары серверов) не будет делиться между портами.
В такой ситуации трафик нужно делить уровнем выше, при помощи соответствующих стандартов multipath, например, в случае Microsoft SMB3 для хранения образов Hyper-V, после минимальных настроек будет работать SMB3 Multichannel, который действительно разделит трафик между портами, причём кроме поддержки Jumbo Frames от коммутатора ничего не требуется.
Ещё стоит заострить внимание на вопросе обновления программного обеспечения. От правила «каменного века» IT-технологий «работает — не трогай» уже пора отказаться по соображениям безопасности. Вот тут во весь рост встаёт вопрос сдвоенных контроллеров, кластеризации самой системы хранения для обеспечения обновления без downtime.
SAS-системы в таком случае выигрывают — регулярно обновлять там, практически, нечего, а сдвоенная шина предусмотрена самим стандартом SAS, и, практически, «бесплатна».
В то же время системы более высокоуровневого хранения имеют полноценную операционную систему, а её нужно регулярно обновлять. Регулярное же обновление означает либо регулярные (плановые) отключения (что может быть не страшно, например, для небольшой организации, работающей строго до 6 вечера), либо практическое удвоение (а, возможно, и многократное увеличение) бюджета при покупке «двухголовых» систем хранения с возможностью обновляться «на лету».
В итоге, за фронтоном высокоуровневой SAN-системы может прятаться всё тот же SAS DAS на два сервера.
Ну и, конечно, в статье ни слова о SSD. Время, когда огромными массивами дисков компенсировали их ужасающий seek time, к счастью, прошли. Hot tier на SSD полностью переворачивает подход к созданию дисковых систем хранения. И тут у «голого» SAS проблемы: SSD-накопители с интерфейсом SAS стоят (на мой взгляд, абсолютно неоправданно) как самолёт, причём не в сравнении с накопителями домашнего класса, которые в качестве hot tier продержатся месяц, а с вполне серверными SATA-решениями. Interposers для превращения SATA SSD-накопителя в SAS существуют, но продаются практически из-под полы, уж не знаю, из-за картельного ли сговора, или очередные патенты запрещают.
Стоит также напомнить про гиперконвергентные системы. Сложно сказать, заменят ли они традиционные СХД, но в «конспекте админа» хотя-бы пометку о их существовании сделать стоит.
Про SSD и конвергентные решения не писалось специально – это для следующей статьи о СХД в более крупных инфраструктурах. И потом, о совсем «магии» не стоит писать в статье про основы и простые решения, чтобы не получить каши.
За дельные дополнения спасибо! Особенно про обновление ПО и нюанс SAN в этом плане – хороший повод для размышлений.
За дельные дополнения спасибо! Особенно про обновление ПО и нюанс SAN в этом плане – хороший повод для размышлений.
Как раз штатную функцию Windows Server уже двух последних версий — Storage Tiers я б к «магии» не относил, а вписывал бы в каждый букварь. Самую базовую конфигурацию из 2 SATA HDD + 2 SATA SSD в сервере начального уровня можно собрать за копейки, получив производительность и объём, которые и не снились раньше. Огромному количеству компаний, особенно в сегменте SMB, ничего другого вообще не нужно, то есть можно это первым абзацем в «конспект» вписывать, а дальше уже «если вам мало, то… <всё остальное содержание статьи>».
НЛО прилетело и опубликовало эту надпись здесь
Статья все же ориентирована на аппаратные решения, поэтому программные массивы во внимание не брались. Честно говоря, у меня до сих пор предубеждение к «боевым» стораджам на базе Windows.
Да у вас вообще очень много «предубеждений», я смотрю из текста.
Простите, а что такое «аппаратные» SAN системы хранения в вашей терминологии? Всё, что в качестве операционной системы использует не Windows (Storage) Server? Или, наоборот, только SAS-полки в JBOD, подключенные к non-RAID HBA серверов приложений?
Все то, что управляется специализированной ОС, интегрированной в прошивку. Если широко смотреть на вопрос, то конечно любой коммутатор или дисковая полка в той или иной мере управляются софтом. Но ведь речь не о формальных признаках.
Вот о том и речь, по каким признакам вы делите? Linux-сервер Synology DS414 из вашей статьи — «аппаратное» решение? Или, к примеру, Data ONTAP — «аппаратное»?
Это уже вопрос формата «к чему отнести лифтбэк — к хэтчбэкап или седанам» :) Давайте для простоты так определимся. Железные стораджи — это классические системы со специальной ОС, расширение которой строго ограничено производителем.
Насчет СХД NetApp и их операционки ONTAP интересный вопрос. отнесете ли вы его не к аппаратному только потому что там в основе FreeBSD? В оборудовании Juniper стоит Junos, так же выросшая на FreeBSD. На тех же EMC Clariion в качестве ОС стоит Windows Storage Server. Они теперь тоже софтварные? :)
Имхо все то, что поставляется в комплекте с «родным» железом — аппаратное решение. А всякие ПСХД, например ONTAP Select, Ceph, Gluster, VSAN и т.п. это уже программное решение.
Имхо все то, что поставляется в комплекте с «родным» железом — аппаратное решение. А всякие ПСХД, например ONTAP Select, Ceph, Gluster, VSAN и т.п. это уже программное решение.
Я ни к чему их не отнесу, потому что считаю, что такое разделение — надуманное, в особенности для SAN, особенно в 2016 году.
Автор разделил, на основании своих «предубеждений» системы хранения на те, что достойны первой (это уже согласно комментариям, а изначально написано «Мы раздумываем над публикацией других статей по серверным технологиям») главы «конспекта», и на те, которые он считает «магией». Я предложил включить в список хотя бы упоминание о пропущенных целых классах систем, иначе складывается впечатление (например, у начинающего сисадмина, для которого, по идее, писался этот «конспект»), что на основании данной статьи можно уже идти делать выбор, что тут подробно расписаны все варианты.
Автор разделил, на основании своих «предубеждений» системы хранения на те, что достойны первой (это уже согласно комментариям, а изначально написано «Мы раздумываем над публикацией других статей по серверным технологиям») главы «конспекта», и на те, которые он считает «магией». Я предложил включить в список хотя бы упоминание о пропущенных целых классах систем, иначе складывается впечатление (например, у начинающего сисадмина, для которого, по идее, писался этот «конспект»), что на основании данной статьи можно уже идти делать выбор, что тут подробно расписаны все варианты.
Кстати, за дополнение по LACP тоже отдельное спасибо. Ошибся малость, подправлю в тексте :)
lacp, 2 vlan, multipath iscsi
вот вам ответ, чтобы всё балансилось, смотрите шире ;)
тестировалось на 2,4,8 линках с 8 клиентами
вот вам ответ, чтобы всё балансилось, смотрите шире ;)
тестировалось на 2,4,8 линках с 8 клиентами
Немного занудства насчет SAS:
Зонирование поддерживают все экспандеры, начиная с SAS2 (см. стандарт T10 zoning). До стандартизации зонирование появилось в SAS-1 свитчах для блейдов HP.
Отличие SAS-свитчей не поддержке зонирования, а в приспособленности для практического использования. Форм-фактор — корпус с внешними портами; наличие удобного средства управления зонированием.
LSI 6160 уже несколько лет, IMHO, можно считать неактуальным продуктом. HCL и прошивки давным-давно не обновляются. У LSI (теперь Avago) когда-то были большие планы насчет SAS-свитчей, даже новую модель, с большим числом портов и SAS3 готовили, но не сложилось.
P.S. Копирайтное занудство. Картинка с двумя хостами и СХД является слегка модифицированной версией картинки с нашей статьи о Storage Spaces. Я уверен, что это не Ваша вина, поиск по гуглокартинкам показывает уже модидифицированный вариант — её подправили и утянули в прошлом году для другой хабрастатьи.
Зонирование поддерживают все экспандеры, начиная с SAS2 (см. стандарт T10 zoning). До стандартизации зонирование появилось в SAS-1 свитчах для блейдов HP.
Отличие SAS-свитчей не поддержке зонирования, а в приспособленности для практического использования. Форм-фактор — корпус с внешними портами; наличие удобного средства управления зонированием.
LSI 6160 уже несколько лет, IMHO, можно считать неактуальным продуктом. HCL и прошивки давным-давно не обновляются. У LSI (теперь Avago) когда-то были большие планы насчет SAS-свитчей, даже новую модель, с большим числом портов и SAS3 готовили, но не сложилось.
P.S. Копирайтное занудство. Картинка с двумя хостами и СХД является слегка модифицированной версией картинки с нашей статьи о Storage Spaces. Я уверен, что это не Ваша вина, поиск по гуглокартинкам показывает уже модидифицированный вариант — её подправили и утянули в прошлом году для другой хабрастатьи.
У LSI (теперь Avago) когда-то были большие планы насчет SAS-свитчей, даже новую модель, с большим числом портов и SAS3 готовили, но не сложилось.
Вроде даже продавали модель под SAS3 через OEM-канал.
Спасибо за статью, получилось весьма интересно. Планируется ли в будущем обзор технологий доступа к информации, расположенной в SAN? Например, могли бы быть интересны реальные практики общего доступа к данным в SAN/NAS.
Спасибо за статью. Давно интересует вопрос про размер тома iSCSI для виртуальных машин. Допустим есть у меня хранилище где стоит много дисков и общий размер 3Tb. Как правильнее что ли, один том на 3Tb или несколько по 500-750Gb?
Вот про FCoE:
Это объяснение из серии «потому, что перпендикуляр».
Настоящие «oE»-решения реально работают поверх обычного Ethernet. Примеры — IPX, PPPoE, а по теме статьи — AoE, IP (внутри него может быть iSCSI, CEPH, DRBD, NFS, SMB и так далее). Все они учитывают особенности Ethernet — тот факт, что фрейм может потеряться бесследно в случае перегрузки сети.
Например, AoE работает поверх голого Ethernet (не использует IP), он явно «уровнем ниже» TCP/IP; NFS v2/3 работает поверх UDP, то есть также не использует TCP. И для этих двух сетевых протоколов не заявлены требования особого оборудования. Причём, AoE — это SAN-протокол в чистом виде, блочный.
А FibreChannel не переживает потери фрейма и считает что фреймы вообще никогда не теряются и не портятся. Это несовместимо с Ethernet. Чтобы совместить, нужно было FC научить выживать в сети с потерями фреймов — и тогда он мог бы заработать в обычном Ethernet.
Вместо этого решили научить Ethernet учитывать особенности FC, то есть, не терять фреймы в случае перегрузки. Это уже не совсем Ethernet. И именно поэтому требуется особое оборудование «с поддержкой FCoE», а не потому, что он «уровнем ниже TCP/IP» или в таком духе.
Поскольку протокол работает ниже уровня TCP\IP, то простой коммутатор не подойдет.
Это объяснение из серии «потому, что перпендикуляр».
Настоящие «oE»-решения реально работают поверх обычного Ethernet. Примеры — IPX, PPPoE, а по теме статьи — AoE, IP (внутри него может быть iSCSI, CEPH, DRBD, NFS, SMB и так далее). Все они учитывают особенности Ethernet — тот факт, что фрейм может потеряться бесследно в случае перегрузки сети.
Например, AoE работает поверх голого Ethernet (не использует IP), он явно «уровнем ниже» TCP/IP; NFS v2/3 работает поверх UDP, то есть также не использует TCP. И для этих двух сетевых протоколов не заявлены требования особого оборудования. Причём, AoE — это SAN-протокол в чистом виде, блочный.
А FibreChannel не переживает потери фрейма и считает что фреймы вообще никогда не теряются и не портятся. Это несовместимо с Ethernet. Чтобы совместить, нужно было FC научить выживать в сети с потерями фреймов — и тогда он мог бы заработать в обычном Ethernet.
Вместо этого решили научить Ethernet учитывать особенности FC, то есть, не терять фреймы в случае перегрузки. Это уже не совсем Ethernet. И именно поэтому требуется особое оборудование «с поддержкой FCoE», а не потому, что он «уровнем ниже TCP/IP» или в таком духе.
Уважаемые знатоки, а может кто-нибудь посоветовать решение типа Synology, но с нормальной ценой? =))
Либо решение вот такой беды: в домашний роутер воткнуты стационарный комп с кучей дисков и ноутбук. Всё по витой паре. На компе диски расшарены и он играет роль сетевой хранилки.
Но вот какая штука — время от времени доступ к дискам прекращается. Делаешь отключение/включение сетевой карты (встроенная) — помогает.
Пытался решить покупкой дискретной сетевухи — не помогло. Пытался обновить драйвера на встроенной — ОС не дает…
На обоих компах Вин 10.
Либо решение вот такой беды: в домашний роутер воткнуты стационарный комп с кучей дисков и ноутбук. Всё по витой паре. На компе диски расшарены и он играет роль сетевой хранилки.
Но вот какая штука — время от времени доступ к дискам прекращается. Делаешь отключение/включение сетевой карты (встроенная) — помогает.
Пытался решить покупкой дискретной сетевухи — не помогло. Пытался обновить драйвера на встроенной — ОС не дает…
На обоих компах Вин 10.
самым дешевым и нормальным имхо будет покупка мини-итх корпуса с двумя винтами и пассивным охлаждением, чтоб спать не мешал. ну и ставить ось по желанию.
из готовых решений для дома мне нравится wd mycloud, простенько, работает и типа облако, можно фоточки на смартфоне друзьям показывать.
а так по вашим симптомам похоже на проблемы со статикой или кабелем или портом в роутере. я б порекомендовал проверить заземление, сменить патчкорд и порт на роутере (или сам роутер).
из готовых решений для дома мне нравится wd mycloud, простенько, работает и типа облако, можно фоточки на смартфоне друзьям показывать.
а так по вашим симптомам похоже на проблемы со статикой или кабелем или портом в роутере. я б порекомендовал проверить заземление, сменить патчкорд и порт на роутере (или сам роутер).
Есть такое — бегает напряжение (старый фонд)…
Да, хотел собрать на Ксеоне 5450, который популярен сейчас на Али, но под него не найти мать на 775 сокете с ДДР3 памятью… Хочется 16 гиг памяти, а ДДР2 столько не позволяет…
Да, хотел собрать на Ксеоне 5450, который популярен сейчас на Али, но под него не найти мать на 775 сокете с ДДР3 памятью… Хочется 16 гиг памяти, а ДДР2 столько не позволяет…
может вам будет достаточно нормального бесперебойника?:)
а так я в свое время делал домашний маленький нас с 2гб оперативки, атомом то ли 330 то ли 570 — уже не помню, и пассивным охлаждением. корпус собрал сам из коробки, блок питания — PicoPsu. воткнул туда по приколу нексенту (баловался заодно с айскази). производительности хватило за глаза, 16гб и ксеон не нужен… или вы хотите что-то ещё держать на домашнем насе?
а так я в свое время делал домашний маленький нас с 2гб оперативки, атомом то ли 330 то ли 570 — уже не помню, и пассивным охлаждением. корпус собрал сам из коробки, блок питания — PicoPsu. воткнул туда по приколу нексенту (баловался заодно с айскази). производительности хватило за глаза, 16гб и ксеон не нужен… или вы хотите что-то ещё держать на домашнем насе?
Да, хотел бы еще типа домашнего сервака поднять, для экспериментов.
Интересно, есть ли еще где-нибудь старые материнки с 775 сокетом и ДДР 3? Будет жаль если не сыщу, потому что дешевую альтернативу Ксеону 5450 не найти…
Интересно, есть ли еще где-нибудь старые материнки с 775 сокетом и ДДР 3? Будет жаль если не сыщу, потому что дешевую альтернативу Ксеону 5450 не найти…
их вполне можно найти. но ЕМНИП те, что я встречал не поддерживали больше 8гб памяти. может есть смысл поискать на LGA771? чтоб ещё и переходнички не делать.
или же посмотреть на решения на сокете 1366, оно будет чуть дороже, зато без переходничков в сокет и подобной мути.
или же посмотреть на решения на сокете 1366, оно будет чуть дороже, зато без переходничков в сокет и подобной мути.
О, круто, не знал)) Получается 5450 подходит и на эти сокеты?
Я оталикиваюсь именно от проца, так как мощный и дешевый. Но вот с материнками — беда.
Я оталикиваюсь именно от проца, так как мощный и дешевый. Но вот с материнками — беда.
если вы про 771 — то 5450 он на 771 сокете. в 775 он подходит после вырезания ключей и паяния ножек (или покупания спецательных переходничков).
а сокет 1366 — уже чуть поновее, и там уже надо искать другие процессоры, типа 5650, например. ну или первое поколение i7. на авитах и тому подобных попадаются неплохие железяки за умеренную стоимость. впрочем, тут уж смотря что вы вкладываете в понятие «нормальная цена»
а сокет 1366 — уже чуть поновее, и там уже надо искать другие процессоры, типа 5650, например. ну или первое поколение i7. на авитах и тому подобных попадаются неплохие железяки за умеренную стоимость. впрочем, тут уж смотря что вы вкладываете в понятие «нормальная цена»
НЛО прилетело и опубликовало эту надпись здесь
Я 3 года назад купил материнку за 1500 р со впаяным атомом, во круг туда 2 плашки ддр3 по 4гб. Поставил 2 ссд 120 (лучше по 250 там tbw в разы больше) плюс два винта по 6тб. Резистор на кулер что бы сбавить обороты для тишины и все это в корпус с большим тихим кулером на сквозной продув. (Всю картину тишины портят диски голд, и блок питания. Но голды это что-то, хрустят так что ночью подпрыгивал, в итоге в кладовку все спрятал)
А дальше установил на это железо truenas (он умеет ставить систему на ссдшки делая из них zfs зеркало). Ну а дальше все вполне очевидно. Ну ещё снапшоты включить надо по расписанию, в теории должны спасти от шифровальщика по самбе.
Короче, винты были, БП был, корпус какой то был, и итоговый бюджет на эту файлопомойку у меня вышел 1700 рублей (материнка+резистор на кулер)
И бонусом трунас ещё умеет собирать данные с облаков по расписанию (делать оффлайн бэкап всяких там гугл, яндекс и мейл облаков) а с учётом снэпшотов zfs ещё и с версионностью.
К плюсам решений на FC можно отнести:
Возможность построения территориально распределенной SAN;
Минимальная латентность;
Высокая скорость передачи данных;
Возможность репликации и создания снапшотов силами дискового массива.
Не понял, куда всё это делось у iSCSI и FCoE? И почему не указана такая особенность, как Flow control? Или это плюсы по сравнению с SAS только?
А почему iSCSI ограничен 10 гигабитами, а то время как для FC заявлены современные 128? Я отстал немного от темы, но мне кажется 40 Гб/с уже давно доступны для ethernet.
В небольших организациях обычно применяют структуру с одним коммутатором (single-switch), когда один сервер через один коммутатор подключается к дисковому массиву. Такая схема составляет основу остальных топологий: каскад (cascade), решетка (mesh) и кольцо (ring).
Что-то представление кольца из одного коммутатора вызывает у меня короткое замыкание. В целом немного противоестественная картина — FC выбирают, когда нужна не только скорость, но и надёжность, а это минимум 2 фабрики, т.е. 2 свича.
В целом по статье, сведения безусловно полезные, но, боюсь, если бы я не владел уже описанной в ней информацией, я бы мало что понял. Уж больно фрагментарно и намешано в кучу коней и людей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Конспект админа: отличие микроскопа от молотка при построении SAN (обновлено)