Конспект админа: отличие микроскопа от молотка при построении SAN (обновлено)

Конспект админа: отличие микроскопа от молотка при построении SAN (обновлено)
Хранилища данных*, Системное администрирование*, ИТ-инфраструктура*, SAN*, Блог компании Сервер Молл

Однажды один из клиентов компании-интегратора, где я работал, попросил оперативно нарисовать проект небольшой системы хранения данных. Как назло, специальный человек по SAN оказался недоступен и задачу поручили мне. На тот момент мои знания по СХД сводились к непробиваемой идее "Fibre Channel – это круто, а iSCSI – не очень".
Для всех тех, кто попал в похожую ситуацию или немного интересуется темой SAN, мы подготовили цикл материалов в формате "конспект". Сегодняшняя статья посвящена технологиям хранения для небольших и средних организаций. Постараюсь не занудствовать с теорией и использовать побольше примеров.
СХД различные и в меру необычные
Если инженер не особенно знаком с сетями хранения данных (СХД), то выбор подходящего устройства часто начинается с изучения рынка в преломлении собственных стереотипов. Например, я в свое время обычно останавливался на простых DAS-системах, что удивительно дополняло своей нелогичностью тезис про "крутость" Fibre Channel. Зато DAS был понятным и не требовал чтения длинных руководств администратора и погружения в темный мир сетей хранения.
Если в организации просто заканчивается место на общем сетевом диске, то хватит и недорогого сервера с относительно высокой плотностью дисков, в качестве задела на будущее. Из специализированных систем неплохо подойдет сетевое файловое хранилище (NAS), вроде Synology DS414 SLim. На нем и общие папки создавать удобно, и права гибко настраиваются, и с Active Directory интеграция есть.

Чем мне нравятся хранилища Synology, так это удобным интерфейсом с множеством плагинов на любые сценарии использования. Но поведение у них бывает весьма странным. Например, у одного заказчика был Synology DS411+II. Работал прекрасно до очередной перезагрузки, после которой не включился. Не спрашивайте, как я до этого дошел, но алгоритм запуска после сбоя был следующий:
1. Вынуть все диски, включить устройство, выключить устройство;
2. Воткнуть один диск, включить устройство, выключить устройство;
3. Воткнуть второй диск, включить устройство, выключить устройство;
4. Повторить для третьего и четвертого диска. После установки четвертого диска, устройство включается и работает.
Способ был опубликован на форуме Synology и оказалось, что я не один такой везучий. С тех пор предпочитаю небольшие серверы с GNU\Linux на борту, у них хотя бы с диагностикой проще.

Из сборок для NAS могу порекомендовать Openmediavault.
Все усложняется когда нужно нарастить дисковый объем имеющихся серверов или появляются мысли о высокой доступности. Тут-то и возникает соблазн построить полноценную NAS или впасть в другую крайность, ограничившись простой дисковой полкой DAS.
Пара слов о том, что такое SAN и DAS. Просто освежить память.
В этой статье я не буду касаться программных реализаций, вроде Storage Spaces в среде Windows, а ограничусь железными и архитектурными нюансами СХД.
Зачем отдельная сеть хранения
Начнем с типовых решений для хранения данных, которые предполагают использование специальных сетей и интерфейсов, так как с ними больше всего вопросов.
Самым недорогим способом организации SAN является интерфейс Serial Attached SCSI (SAS). Тот самый, с помощью которого подключаются диски в любом современном сервере. Используют SAS и для прямого подключения внешнего дискового массива к серверу.
Для массива DAS возможна организация отказоустойчивого подключения к нескольким серверам. Делается это с помощью Multipath, технологии коммутации клиента и СХД по нескольким маршрутам. Но большей популярностью пользуется разделение дисков между серверами, которые уже самостоятельно собирают из них группы RAID и делят на тома. Подобная схема называется "Разделяемый JBOD".
Для подключение к серверу используются адаптеры (HBA) под конкретный интерфейс, которые просто позволяют ОС увидеть готовые дисковые тома.

Стоит отметить, что SAS поддерживает три стандарта:
- SAS-1, со скоростью 3 Гб/с на устройство;
- SAS-2, со скоростью 6 Гб/с;
- SAS-3, предоставляющий уже 12 Гб/с.
При планировании архитектуры стоит также иметь в виду отличия в разъемах SAS, что часто приводит к путанице при заказе кабелей. Самыми популярными при подключении внешнего оборудования являются SFF-8088 (mini-SAS) и SFF-8644 (mini-SAS HD).
Являясь частностью SCSI, SAS поддерживает экспандеры, что позволяет подключать до 65 535 устройств к одному контроллеру и порту. Конечно, цифра скорее теоретическая и не учитывает различные накладные расходы. Чаще всего встречаются контроллеры с реальным ограничением в 128 дисков, но масштабировать подобный SAN для двух и более серверов простыми экспандерами уже не так удобно. В качестве более адекватной альтернативы можно использовать коммутаторы SAS. По сути, это те же экспандеры, но с поддержкой распределения ресурсов по серверам, т.н "зонирование". Например, для стандарта SAS-2 наибольшей популярностью пользуется LSI 6160.

С помощью коммутаторов SAS возможна реализация отказоустойчивых схем для нескольких серверов без единой точки отказа.

Из плюсов использования SAS можно отметить:
- Низкую стоимость решения;
- Высокую пропускную способность – даже при использовании SAS-2 получится 24 Гб/с на каждый порт контроллера;
- Низкая латентность.
Не обошлось и без минусов:
- Отсутствуют механизмы репликации средствами дискового массива;
- Есть ограничение на длину кабельного сегмента: обычный медный SAS-кабель длиннее 10 м не встречается, активный – не более 25 м. Существуют и оптические кабели SAS с ограничением в 100 метров, но они ощутимо дороже.
В качестве типового решения для малых и средних организаций разберем создание небольшого отказоустойчивого кластера виртуальных машин. Под кластер выделим два узла с единственным дисковым массивом. В качестве условного среднего объема дискового тома выберем 1 ТБ.

Замечу, что программными решениями вроде StarWind Native SAN можно получить такой же кластер без отдельного дискового массива, или же с простыми JBOD. Кроме того, большинство гипервизоров поддерживают в качестве хранилищ сетевые ресурсы NFS или SMB 3.0. Но в программных реализациях больше нюансов и «слабых звеньев» из-за большей сложности системы. Да и производительность обычно ниже.

Для сборки такой системы понадобится:
- Два сервера;
- Дисковый массив;
- HBA для серверов;
- Соединительные кабели.
Дисковый массив возьмем для примера HP MSA 2040 с двенадцатью отсеками под HDD. Для подключения будем использовать SAS 3.0 на скорости 12 Гб/с. Посчитаем первым попавшимся конфигуратором общую стоимость системы хранения:

А вот и схема подключения:

Каждый сервер будет соединятся с каждым контроллером СХД для Multipathing.

На мой взгляд, SAS 3.0 оптимален, если не нужны распределенные SAN-сети и не требуется детальное разграничение прав доступа к СХД. Для небольшой организации так можно достичь отличного баланса цены и производительности.

После приобретения второго массива в будущем станет возможным соединение каждого сервера с контроллером каждой дисковой полки, но при росте числа клиентов это серьезно усложнит архитектуру. Для большего числа клиентов лучше приобрести один SAS коммутатор. Или два, для построения отказоустойчивого решения.
Традиционным выбором для построения SAN является Fibre Channel (FC) – интерфейс, связующий узлы сети по оптическому волокну.
FC поддерживает несколько скоростей: от 1 до 128 Гб/с (стандарт 128GFC вышел как раз в 2016). В основном используются 4GFC, 8GFC и 16GFC.
Существенные различия по сравнению с SAS-системами проявляются при проектировании крупных SAN:
- Расширение производится не за счет экспандеров, а возможностями топологии сети;
- Максимальная длина кабеля при использовании одномодового оптоволокна может достигать 50 км.
В небольших организациях обычно применяют структуру с одним коммутатором (single-switch), когда один сервер через один коммутатор подключается к дисковому массиву. Такая схема составляет основу остальных топологий: каскад (cascade), решетка (mesh) и кольцо (ring).
Наиболее масштабируемая и отказоустойчивая схема называется "центрально-распределенная" (core-edge). Она напоминает известную всем сетевую топологию “звезда”, но только в середине два центральных коммутатора, распределяющих трафик по периферийным. Частным случаем этой схемы является “коммутируемая архитектура” (switched fabric), без периферийных коммутаторов.
При проектировании стоит обратить внимание на разные типы трансиверов. Это специальные модули, которые преобразуют цифровой сигнал в оптический, для чего используются светодиоды или лазерные излучатели. Трансиверы поддерживают разные длины волны и разные оптические кабели, что влияет на протяженность сегмента.
Есть два типа трансиверов:
- Коротковолновые (Short Wave, SW, SX) – подходят только для многомодовых волокон;
- Длинноволновые (Long Wave, LW, LX), совместимы с многомодовым и одномодовым волокном.
К обоим типам кабель подключается разъемом LC, а вот SC-разъемы встречаются довольно редко.

Типичный HBA c двумя портами FC

При выборе оборудования для SAN не лишним будет проверить все компоненты по таблицам совместимости производителя железа. Активное сетевое оборудование всегда лучше выбирать одного бренда, чтобы избежать проблем совместимости даже в теории – это стандартная практика для подобных систем.

К плюсам решений на FC можно отнести:
- Возможность построения территориально распределенной SAN;
- Минимальная латентность;
- Высокая скорость передачи данных;
- Возможность репликации и создания снапшотов силами дискового массива.
На другой чаше весов традиционно лежит стоимость.
Системы хранения из раздела про SAS можно построить и на 16GFC, заменив лишь HBA и контроллер дисковой полки. Стоимость при этом вырастет уже до 1 845 790 ₽.

В своей практике я встречал у заказчика даже построенный на FC массив DAS, заполненным дисками менее, чем наполовину. Почему не использовали SAS? Самый оригинальный ответ был такой: «а что, можно было?».

Пара слов о логических портах.
Статья была бы неполной без упоминания варианта построения SAN на InfiniBand. Этот протокол позволяет достичь действительно высоких скоростей передачи данных, но по стоимости выходит далеко за рамки SMB.
Использование привычного Ethernet
Можно обойтись и без изучения новых видов сетей, используя старый добрый Ethernet.
Популярный протокол для создания SAN в Ethernet-сетях называется Internet Small Computer Systems Interface (iSCSI). Строится он поверх TCP\IP, и основной его плюс в приличной работе по обычной гигабитной сети. В обиходе такие решения часто называют "бесплатный SAN". Разумеется, гигабита под серьезные задачи не хватит, и к вашим услугам сети 10 Гб/с.
К безусловным плюсам можно отнести низкую стоимость базового оборудования. Так как iSCSI реализуется программно, можно установить соответствующие приложения на обычные серверы. Большинство NAS класса SOHO поддерживают этот протокол изначально.

У заказчика однажды остро встал вопрос перемещения Exchange 2003 с умирающего сервера. Решили виртуализировать его с минимальным простоем. Для этого подняли iSCSI-target на том самом NAS Synology DS411 из первой части статьи и подключили к Exchange. Далее перенесли туда БД и мигрировали на MS Virtual Server 2005 c помощью disk2vhd. После успешной миграции перенесли базу обратно. Позже такие операции проводились при переходе с MS Virtual Server на VMware.

Разумеется, для построения SAN на iSCSI, даже если для задач хватает и гигабитной сети, не стоит "выпускать" его в общий LAN. Работать оно будет, но широковещательные запросы и прочий служебный трафик непременно скажутся на скорости и создадут помехи пользователям. Лучше построить отдельную изолированную сеть со своим оборудованием. Или, в крайнем случае, хотя бы выделить подсеть с iSCSI в отдельный VLAN. Стоит отметить, что для достижения максимальной производительности таких систем необходимо включать поддержку Jumbo Frames на всем пути следования пакетов.
В качестве меры экономии бюджета может возникнуть мысль об объединении гигабитных портов при помощи агрегации каналов (LACP). Но, как правильно заметил VitalKoshalew в комментариях, реальной балансировки между отдельным сервером и хранилищем с помощью LACP не получится. Более правильным бюджетным решением будет использование технологий Multipath на верхних уровнях модели OSI.
К слову, совсем правильное iSCSI-решение на базе 10 Гб сети, с поддерживающими аппаратное ускорение iSCSI сетевыми картами и соответствующими коммутаторами приближается по стоимости к FC.

Подобная схема сети возможна благодаря тому, что iSCSI работает поверх TCP\IP.
Из интересных решений на базе iSCSI можно отметить работу тонких клиентов без сервера терминалов – вместо локальных дисков используется том iSCSI. Гигабитной сети вполне достаточно для такой работы, а реализовать что-либо подобное другими средствами не так просто.
Плюсы решения:
- Низкая стоимость;
- Возможность построения территориально распределенной сети;
- Простота проектирования и обслуживания.
Минусы:
- Задержки при обращении к данным могут быть существенными, особенно при работе с пулом виртуальных машин;
- Повышенная нагрузка на процессор, если не используются специальные HBA с аппаратной поддержкой iSCSI.
Есть и более "взрослая" альтернатива iSCSI. Можно использовать ту же сеть Ethernet, но протокол хранения завернуть непосредственно в кадры Ethernet, минуя TCP\IP. Протокол называется Fibre Channel over Ethernet (FCoE) и для работы использует Ethernet 10 Гб. Помимо традиционной оптики, можно использовать специальные медные кабели или витую пару категории 6a.
Важное отличие от FC в том, что порт Ethernet можно использовать совместно с TCP\IP. Для этого нужны специальные сетевые адаптеры, так называемые Converged Network Adapter (CNA) с поддержкой FC и FCoE, хотя есть и программные решения. Поскольку протокол работает ниже уровня TCP\IP, то простой коммутатор не подойдет. Кроме того, обязательно должна быть поддержка Jumbo Frames и Data Center Bridging (DCB, иногда встречается Data Center Ethernet). Подобные решения обычно стоят дороже (например, Cisco серии Nexus).

В теории, FCoE можно запустить и в гигабитной сети без использования DCB, но это весьма неординарное решение, для которого я не встречал рассказов об успешных запусках.

Если вернуться к нашему маленькому, но гордому кластеру виртуализации, то для него решения на 10 Гб/с iSCSI и FCoE будут практически одинаковыми по стоимости, но в случае с iSCSI можно использовать дешевые гигабитные сети.
Также стоит упомянуть и довольно экзотичный протокол ATA over Ethernet (AoE), схожий по своей работе с FCoE. Дисковые массивы с ним – редкость, обычно используются программные решения.
Что в итоге
Выбор конкретной реализации системы хранения требует вдумчивого изучения конкретной ситуации. Не стоит подключать дисковый массив с помощью FC просто потому, что "оптика" звучит гордо. Решение на SAS даст аналогичную или даже большую производительность там, где оно архитектурно уместно. Если не брать в расчет стоимость и сложности обслуживания, то существенным отличием между всеми описанными технологиями подключения СХД будет дистанция соединений. Эту мысль хорошо иллюстрирует один из кадров презентации SNIA:

Если после прочтения статьи хотите подробнее изучить самобытный мир SAN, могу порекомендовать следующие бестселлеры:
Наилучшие практики построения FC SAN
Мы раздумываем над публикацией других статей по серверным технологиям в формате "ликбез", поэтому было бы здорово получить от вас обратную связь в виде оценки этого материала. Если какие-то темы вам особенно интересны – обязательно расскажите о них в комментариях.
сети хранения данных

11k
- Автор: @dimskiy
- Похожие публикации
- Комментарии (36)
- Спасибо за статью.
- Вот еще один очень хороший и компактный документ.
  - dimskiy 18 октября 2016 в 22:32
  - Спасибо, добавил к списку литературы
- VitalKoshalew 18 октября 2016 в 23:10
- Не буду разводить холивар на общую тему ~~кит vs. слон~~ какой протокол для чего лучше, но кое-что хотелось бы уточнить. Следующая фраза в большинстве реальных применений неверна:

Если остро стоит вопрос экономии бюджета и сетевое оборудование 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 существуют, но продаются практически из-под полы, уж не знаю, из-за картельного ли сговора, или очередные патенты запрещают.
Стоит также напомнить про гиперконвергентные системы. Сложно сказать, заменят ли они традиционные СХД, но в «конспекте админа» хотя-бы пометку о их существовании сделать стоит.
- dimskiy 19 октября 2016 в 00:52
Про SSD и конвергентные решения не писалось специально – это для следующей статьи о СХД в более крупных инфраструктурах. И потом, о совсем «магии» не стоит писать в статье про основы и простые решения, чтобы не получить каши.
За дельные дополнения спасибо! Особенно про обновление ПО и нюанс SAN в этом плане – хороший повод для размышлений.
- VitalKoshalew 19 октября 2016 в 02:29
Как раз штатную функцию Windows Server уже двух последних версий — Storage Tiers я б к «магии» не относил, а вписывал бы в каждый букварь. Самую базовую конфигурацию из 2 SATA HDD + 2 SATA SSD в сервере начального уровня можно собрать за копейки, получив производительность и объём, которые и не снились раньше. Огромному количеству компаний, особенно в сегменте SMB, ничего другого вообще не нужно, то есть можно это первым абзацем в «конспект» вписывать, а дальше уже «если вам мало, то… <всё остальное содержание статьи>».
- НЛО прилетело и опубликовало эту надпись здесь
- dimskiy 19 октября 2016 в 12:17
Статья все же ориентирована на аппаратные решения, поэтому программные массивы во внимание не брались. Честно говоря, у меня до сих пор предубеждение к «боевым» стораджам на базе Windows.
- romxx 19 октября 2016 в 12:20
Да у вас вообще очень много «предубеждений», я смотрю из текста.
VitalKoshalew 19 октября 2016 в 16:39
Простите, а что такое «аппаратные» SAN системы хранения в вашей терминологии? Всё, что в качестве операционной системы использует не Windows (Storage) Server? Или, наоборот, только SAS-полки в JBOD, подключенные к non-RAID HBA серверов приложений?
- dimskiy 19 октября 2016 в 18:30 (комментарий был изменён)
Все то, что управляется специализированной ОС, интегрированной в прошивку. Если широко смотреть на вопрос, то конечно любой коммутатор или дисковая полка в той или иной мере управляются софтом. Но ведь речь не о формальных признаках.
- VitalKoshalew 19 октября 2016 в 18:51
Вот о том и речь, по каким признакам вы делите? Linux-сервер Synology DS414 из вашей статьи — «аппаратное» решение? Или, к примеру, Data ONTAP — «аппаратное»?
- dimskiy 19 октября 2016 в 21:10
Это уже вопрос формата «к чему отнести лифтбэк — к хэтчбэкап или седанам» :) Давайте для простоты так определимся. Железные стораджи — это классические системы со специальной ОС, расширение которой строго ограничено производителем.
- VitalKoshalew 20 октября 2016 в 02:59 (комментарий был изменён)
- Так Linux-серверы от Synology et al, на которые все желающие ставят торрентокачалки и чуть ли не умный дом, это «железный сторадж»?
- Я не ради упражнений в софизме этот разговор веду, а только чтобы показать, что разделение не имеет смысла, в особенности для SAN.
mikkisse 19 октября 2016 в 21:42 (комментарий был изменён)
Насчет СХД NetApp и их операционки ONTAP интересный вопрос. отнесете ли вы его не к аппаратному только потому что там в основе FreeBSD? В оборудовании Juniper стоит Junos, так же выросшая на FreeBSD. На тех же EMC Clariion в качестве ОС стоит Windows Storage Server. Они теперь тоже софтварные? :)
Имхо все то, что поставляется в комплекте с «родным» железом — аппаратное решение. А всякие ПСХД, например ONTAP Select, Ceph, Gluster, VSAN и т.п. это уже программное решение.
- VitalKoshalew 20 октября 2016 в 03:17
dimskiy 19 октября 2016 в 12:16
Кстати, за дополнение по LACP тоже отдельное спасибо. Ошибся малость, подправлю в тексте :)
neumeika 20 октября 2016 в 00:48
lacp, 2 vlan, multipath iscsi
вот вам ответ, чтобы всё балансилось, смотрите шире ;)
тестировалось на 2,4,8 линках с 8 клиентами
- VitalKoshalew 20 октября 2016 в 03:22
Простите, на какой мой вопрос этот ответ? Я про это написал:

В такой ситуации трафик нужно делить уровнем выше, при помощи соответствующих стандартов multipath

neumeika 20 октября 2016 в 03:42

quartz64 19 октября 2016 в 13:46
Немного занудства насчет SAS:
Зонирование поддерживают все экспандеры, начиная с SAS2 (см. стандарт T10 zoning). До стандартизации зонирование появилось в SAS-1 свитчах для блейдов HP.
Отличие SAS-свитчей не поддержке зонирования, а в приспособленности для практического использования. Форм-фактор — корпус с внешними портами; наличие удобного средства управления зонированием.
LSI 6160 уже несколько лет, IMHO, можно считать неактуальным продуктом. HCL и прошивки давным-давно не обновляются. У LSI (теперь Avago) когда-то были большие планы насчет SAS-свитчей, даже новую модель, с большим числом портов и SAS3 готовили, но не сложилось.
P.S. Копирайтное занудство. Картинка с двумя хостами и СХД является слегка модифицированной версией картинки с нашей статьи о Storage Spaces. Я уверен, что это не Ваша вина, поиск по гуглокартинкам показывает уже модидифицированный вариант — её подправили и утянули в прошлом году для другой хабрастатьи.
- navion 1 ноября 2016 в 19:34

У LSI (теперь Avago) когда-то были большие планы насчет SAS-свитчей, даже новую модель, с большим числом портов и SAS3 готовили, но не сложилось.

Вроде даже продавали модель под SAS3 через OEM-канал.

GhOsT_MZ 19 октября 2016 в 21:06
Спасибо за статью, получилось весьма интересно. Планируется ли в будущем обзор технологий доступа к информации, расположенной в SAN? Например, могли бы быть интересны реальные практики общего доступа к данным в SAN/NAS.
- dimskiy 19 октября 2016 в 21:25
А о какого рода данных идет речь? Просто файловый сервер?
- GhOsT_MZ 20 октября 2016 в 11:06
  - Допустим, просто файловый сервер, но достаточно быстрый, емкий (20ТБ+) и отказоустойчивый. Подобную задачу тяжело решить одним серверов, забитым жесткими дисками, поэтому хотелось бы почитать о том, как реализуются подобные вещи, на что стоит обращать внимание при построении подобных хранилищ.
nitraf 19 октября 2016 в 23:00
Спасибо за статью. Давно интересует вопрос про размер тома iSCSI для виртуальных машин. Допустим есть у меня хранилище где стоит много дисков и общий размер 3Tb. Как правильнее что ли, один том на 3Tb или несколько по 500-750Gb?
merlin-vrn 20 октября 2016 в 12:00 (комментарий был изменён)
Вот про FCoE:

Поскольку протокол работает ниже уровня 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» или в таком духе.
SerJ_82 20 октября 2016 в 16:21
Уважаемые знатоки, а может кто-нибудь посоветовать решение типа Synology, но с нормальной ценой? =))
Либо решение вот такой беды: в домашний роутер воткнуты стационарный комп с кучей дисков и ноутбук. Всё по витой паре. На компе диски расшарены и он играет роль сетевой хранилки.
Но вот какая штука — время от времени доступ к дискам прекращается. Делаешь отключение/включение сетевой карты (встроенная) — помогает.
Пытался решить покупкой дискретной сетевухи — не помогло. Пытался обновить драйвера на встроенной — ОС не дает…
На обоих компах Вин 10.
- avelor 20 октября 2016 в 16:52
самым дешевым и нормальным имхо будет покупка мини-итх корпуса с двумя винтами и пассивным охлаждением, чтоб спать не мешал. ну и ставить ось по желанию.
из готовых решений для дома мне нравится wd mycloud, простенько, работает и типа облако, можно фоточки на смартфоне друзьям показывать.
а так по вашим симптомам похоже на проблемы со статикой или кабелем или портом в роутере. я б порекомендовал проверить заземление, сменить патчкорд и порт на роутере (или сам роутер).
- SerJ_82 20 октября 2016 в 18:17
Есть такое — бегает напряжение (старый фонд)…
Да, хотел собрать на Ксеоне 5450, который популярен сейчас на Али, но под него не найти мать на 775 сокете с ДДР3 памятью… Хочется 16 гиг памяти, а ДДР2 столько не позволяет…
- avelor 20 октября 2016 в 18:32
может вам будет достаточно нормального бесперебойника?:)
а так я в свое время делал домашний маленький нас с 2гб оперативки, атомом то ли 330 то ли 570 — уже не помню, и пассивным охлаждением. корпус собрал сам из коробки, блок питания — PicoPsu. воткнул туда по приколу нексенту (баловался заодно с айскази). производительности хватило за глаза, 16гб и ксеон не нужен… или вы хотите что-то ещё держать на домашнем насе?
- SerJ_82 21 октября 2016 в 09:16
Да, хотел бы еще типа домашнего сервака поднять, для экспериментов.
Интересно, есть ли еще где-нибудь старые материнки с 775 сокетом и ДДР 3? Будет жаль если не сыщу, потому что дешевую альтернативу Ксеону 5450 не найти…
- avelor 21 октября 2016 в 13:02
их вполне можно найти. но ЕМНИП те, что я встречал не поддерживали больше 8гб памяти. может есть смысл поискать на LGA771? чтоб ещё и переходнички не делать.
или же посмотреть на решения на сокете 1366, оно будет чуть дороже, зато без переходничков в сокет и подобной мути.
- SerJ_82 21 октября 2016 в 13:22
О, круто, не знал)) Получается 5450 подходит и на эти сокеты?
Я оталикиваюсь именно от проца, так как мощный и дешевый. Но вот с материнками — беда.
- avelor 21 октября 2016 в 13:42 (комментарий был изменён)
- НЛО прилетело и опубликовало эту надпись здесь
kabal375 3 ноября 2016 в 17:25

К плюсам решений на FC можно отнести:
Возможность построения территориально распределенной SAN;
Минимальная латентность;
Высокая скорость передачи данных;
Возможность репликации и создания снапшотов силами дискового массива.

Не понял, куда всё это делось у iSCSI и FCoE? И почему не указана такая особенность, как Flow control? Или это плюсы по сравнению с SAS только?
А почему iSCSI ограничен 10 гигабитами, а то время как для FC заявлены современные 128? Я отстал немного от темы, но мне кажется 40 Гб/с уже давно доступны для ethernet.

В небольших организациях обычно применяют структуру с одним коммутатором (single-switch), когда один сервер через один коммутатор подключается к дисковому массиву. Такая схема составляет основу остальных топологий: каскад (cascade), решетка (mesh) и кольцо (ring).

Что-то представление кольца из одного коммутатора вызывает у меня короткое замыкание. В целом немного противоестественная картина — FC выбирают, когда нужна не только скорость, но и надёжность, а это минимум 2 фабрики, т.е. 2 свича.
В целом по статье, сведения безусловно полезные, но, боюсь, если бы я не владел уже описанной в ней информацией, я бы мало что понял. Уж больно фрагментарно и намешано в кучу коней и людей.

Page updated

Google Sites

Report abuse