Qlogic 57840 — конвергентная карта, то что у неё медные порты не означает её ограниченность;
С удовольствием послушаем, как можно использовать QLE3442-RJ в режиме, отличном от Ethernet. Напомним, что изначально речь шла о «протоколе подключения через Direct Attach».
2) Direct Attach — поддерживают и SAS полки, вопрос топологий которые она может держать по FC SAN;
Эээ, какая еще топология может быть при Direct Attach кроме прямого подключения (что вытекает из названия)? Что же до топологий FC SAN (раз уж вы упомянули), то тут нет ограничений со стороны СХД.
3) По средством каких манипуляций с алгоритмами расчёта контрольных сумм в RAID 5, вы собираетесь снижать latency при включённом кэшировании операций на запись?
Скорость работы кэша контроллера выше скорости SSD. Отсюда и быстрее ответ хосту об успешной записи. А конкретно расчет контрольных сумм уже давно не влияет на производительность у большинства вендоров СХД, поскольку современные вычислительные мощности справляются с этим на раз-два.
Нам, правда, очень приятно, что вы не просто вдумчиво прочли статью, но и потратили свое время на достаточно длинный комментарий. Попробуем ответить по существу:
Используемая на скиншотах карта Qlogic 57840 имеет медные порты. И потому никак кроме как в виде Ethernet варианте работать не может.
В базе у СХД протокол 10GbE iSCSI. Но Direct Attach поддерживается для всех протоклов (iSCSI и FC)
Не понятно, чем вам не угодил RAID5 на SSD с включенным кэшированием контроллера СХД? Write Back Cache позволяет снизить latency массива.
О каком подвешивании массива вы говорите применительно к Read Ahead? Не перегибайте. Нет тут такого, все прекрасно работает.
Jumbo Frame хорошо утилизирует канал при условии, что его есть, чем нагрузить (3+ Gb/s). В целом, на современном сетевом оборудовании даже при слабой нагрузке большие кадры как минимум не вредят.
Если студия маленькая и все свои IT проблемы решают сами, то чаще всего используют «коробки» либо централизованный NAS. Вопросы резервирования решают в соответствии со своими «представлениями о прекрасном». Да, NAS Qsan имеют ряд функций, помогающим в работе бэкапа. И, да, большинство такого функционала настраивается парой кнопок.
А вот если студия уже заметных размеров, то и подход в организации IT инфраструктуры доверен соответствующим специалистам. Вариант может быть и как вы предлагаете, и как мы описываем — с участием СХД.
Да, собственно, идеи к построению инфраструктуры, приведенные в статье, не являются абсолютными. И ваш подход тоже имеет право на жизнь. Но в реальной жизни грамотные IT спецы в медиа студиях (особенно в малых) встречаются не так уж и часто. Поэтому реализовывать (и поддерживать в последствии) сложные схемы с использованием SDS банально некому. Проще нажать пару кнопок в интерфейсе NAS.
Схема функциональная. Поэтому конкретных «проводочков» на ней нет. Связь между контроллерами для синхронизации и Heartbeat физически осуществляется через бэкплейн.
Два контроллера работают в режиме Active-Active с зеркалированием кэша. Каждый из них осуществляет операции ввода/вывода и работает со «своими» пулами.
Если вам так хочется реализовать подобное, то можно, например, подключать все эти пустующие места пользовательских ПК как сетевые папки к серверу резервного копирования. И уже правилами ПО бекапа перемещать/дублировать резервные копии.
Почему ни одна система резервного копирования не умеет использовать те немаленькие остатки дисков пользователей, когда из них вполне можно сделать распределенный массив для долгосрочных резервных копий?
Такой подход к организации резервного копирования будет подразумевать, что вам как администратору не очень важна сохранность и/или доступность копий. Понятно, что можно организационно и частично программно запретить пользователям расходовать место/удалять файлы/выключать ПК/..., но все же этот «носитель» не полностью подвластен администратору. Видимо, поэтому производители ПО резервного копирования не горят желанием реализовывать подобный функционал. И в качестве хранения бекапов предлагают использовать серверное оборудование (NAS, сервер, лента...)
Для нормальной работы ZFS действительно требуется ~10% незанятого места на пуле. Увы, такова особенность работы этой файловой системы. Причем, удаленные данные внутри LUNов средствами файловой системы хостов на уровне ZFS не удаляются (=не высвобождаются), о чем вам, по вашим словам, и сообщила техподдержка (compression enabled, sdelete). Поэтому грамотным решением в вашем случае является резервирование 10% пространства на пуле как не размеченное. Надеемся, ваш нынешний подрядчик так и поступил.
Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.
Приведены тесты не только для 100% чтения, но и для симуляции реальных задач. И да, с 64КБ блоком производительность будет минимум в 16 раз ниже, чем с 4КБ. Это нормально.
С удовольствием послушаем, как можно использовать QLE3442-RJ в режиме, отличном от Ethernet. Напомним, что изначально речь шла о «протоколе подключения через Direct Attach».
Эээ, какая еще топология может быть при Direct Attach кроме прямого подключения (что вытекает из названия)? Что же до топологий FC SAN (раз уж вы упомянули), то тут нет ограничений со стороны СХД.
Скорость работы кэша контроллера выше скорости SSD. Отсюда и быстрее ответ хосту об успешной записи. А конкретно расчет контрольных сумм уже давно не влияет на производительность у большинства вендоров СХД, поскольку современные вычислительные мощности справляются с этим на раз-два.
А вот если студия уже заметных размеров, то и подход в организации IT инфраструктуры доверен соответствующим специалистам. Вариант может быть и как вы предлагаете, и как мы описываем — с участием СХД.
Два контроллера работают в режиме Active-Active с зеркалированием кэша. Каждый из них осуществляет операции ввода/вывода и работает со «своими» пулами.
Это вы откуда взяли? По вашему два контроллера работают по принципу «кто в лес, кто по дрова»?
Такой подход к организации резервного копирования будет подразумевать, что вам как администратору не очень важна сохранность и/или доступность копий. Понятно, что можно организационно и частично программно запретить пользователям расходовать место/удалять файлы/выключать ПК/..., но все же этот «носитель» не полностью подвластен администратору. Видимо, поэтому производители ПО резервного копирования не горят желанием реализовывать подобный функционал. И в качестве хранения бекапов предлагают использовать серверное оборудование (NAS, сервер, лента...)
Что же касается высвобождения диска из пула, то вы же сами указали, что использовали RAID0 без всякой защиты. Разумеется, извлечение диска из массива приведет к потере данных. Чудес, увы, не будет.