Можно подробнее про не мультипоточность iSCSI? Особенно в свете того, что можно создавать множество сессий к одним и тем же ресурсам.
А почему выше было про миллионы IOPS, а теперь мы пришли к поточной нагрузке?
Вообще меряться скоростью портов достаточно странное занятие, только в очень редких и весьма специфических случаях узким местом становится ширина канала. В случае со случайными нагрузками мелкими и средними блоками это вообще неважно.

Я правильно понял, что для репликации записи на второую ноду в Nutanix используется iSCSI?

Куча документации с подробным описанием того как рабьотают технологии доступно в виде Technical Reports. К примеру TR-4476 про технологии эффективности. Характеристики оборудования доступны в hardware universe куда есть доступ у клиентов и партнёров.

Достойный комментарий, жаль, что половину его можно было не писать, если для сначала разобраться, что SolidFire работает по iSCSI и FC там вообще никаким боком не участвует.

А в чём отличие бесплатных курсов на самом Хекслете и на code-basics?
Не думали отказаться от комментариев на оснвое Disqus в пользу чего-то более легковесного и уважающего приватность, например https://remark42.com/ Там есть импорт из Disqus.

А что с этой технологией для MacOS

Хороший пост.
Я бы для осознания масштабов ещё добавил информацию о том, что FAS3250 была снята с продажи в 2014 году, FAS6220 — в 2015, а миграция происходила на версию ONTAP, которая появилась в конце 2016 года. И после 3250, 6220 вышло уже два поколения новых контроллеров.
Переход на ONTAP 9.1 теоретически уберегает заказчика от таких процедур миграций в будущем. Но главное не затягивать с покупкой новых контроллеров. А то может получится так, что не окажется общей поддерживаемой версии ONTAP. Хотя и в таких ситуациях есть не совсем официальные способы расширить кластер. Вот кусок познавательного треда, где люди мигрировали с 3250 на 8200, объединили их в единый кластер, причем 3250 была на 9.1, а 8200 на 9.2, потому что захотели ADP. Кластер из разных версий собрался, данные без даунтайма утекли на 8200.

Какие варианты NVMeOF поддерживаете?

Результаты тестирования без средней, минимальной и максимальной задержек, а также без указания размера блока не имеют никакого практического смысла.
Локальный raid 0? Оооок. А в продакшн вы такую конфигурацию рекомендуете? Это же нереалистичная конфигурация, никто не будет использовать в реальной инфраструктуре ноды с двумя локальными дисками.

Зачем усложнять с Тинькофф-банком, можно же просто выгрузить все транзакции в csv из личного кабинета.

За какое время происходит переключение путей в растянутой FC фабрике? По вашей логике, если это значение >0, то никто не обеспечивает RTO=0.

Oracle RAC по умолчанию имеет значение disktimeout = 200 секундам. Как с этим жить фанатам RTO= абсолютному 0?

Например, есть крупный банк в России, который имеет 5 метрокластеров. Банк частный. Сколько бы метрокластеров они купили, если бы первый не обеспечил им RTO=0?

Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
Который невозможно поменять? Так себе аргумент
То есть в большинстве случаев, мы получим простой бизнеса.
Предлагаю рассказывать эти байки клиентам, которые успешно используют MetroCluster последние 10+ лет и не имеют простоя бизнеса из-за проблем с хранилищем.

Сам NetApp заявляет, что MetroCluster обеспечивает RPO Zero и RTO under 120 seconds.
NetApp аккуратен в своих заявлениях, даже маркетинговых.
Клиенты более 10 лет используют решение, простоев не имеют. В том числе клиенты в России. Всё проверяется тестированием на реальных задачах.

Всё это происходит быстрее, чем сработает таймаут на стороне хоста.

То есть если мы говорим о решении, которе должно обеспечивать RTO, RPO = 0, то MetroCluster подходит под это определение.

Клиент не покупает СХД в вакууме, он покупает решение.

выполнять Transperent Failover (то есть хост не замечает потерю LUNa в случается выхода из строя одной СХД, теряется только часть путей до LUNа)
Что без проблем позволяет сделать MetroCluster. И Dell EMC VPLEX.

Включать продукты в список по критерию деталей реализации — странный подход. Клиент решает проблему, а не покупает конкретную реализацию технического решения.

C NetApp MetroCluster данные читаются локально, они доступны на обеих площадках. Это можно менять опцией. Запись же идёт по оптимальному пути, используется ALUA, и синхронно попадает на вторую площадку. Да в один момент времени LUN доступен для записи только на одной площадке. Зато с точки зрения надежности позволяет избавиться от решения проблемы когерентности записи данных. Для приложений всё прозрачно. В случае c Pure ActiveCluster надо не забывать о том, что эту проблему необходимо решать на уровне приложений. При одновременной записи в одни блоки в LUNе на разных площадках "побеждает" тот, кто записал последни.

HA-интекрконнект существует не только в 7-mode. Он по-прежнему остался в cluster-mode. NVRAM между контроллерами в паре надо как-то зеркалировать.

А точно ли у заказчика полки DS14 или всё же DS4243? Так как первые точно не поддерживают апгрейд до SAS с помощью IOM12.
По сводной таблице не ясно что означают закрашенные круги в колонке бюджет — больше — дороже или наоборот?

В Тюмень новые алгоритмы видимо еще не завезли :)

Полностью согласен.
Плюс еще и тестирование дисковой подсистемы на данных объемом 500МБ с нулями.

Что за глупости про SnapCenter?
MySQL используется по умолчанию для разворачивания на одном сервере. Поддерживается кластеризация серверов SnapCenter и использование MSSQL в HA. Плагины существуют под Windows, Linux/Unix, Oracle, MSSQL, VMware, SAP/SAP HANA. Плюс community-плагины под MongoDB, MySQL и DB2. Можно и самому собрать плагин для любого другого приложения.
Плагины живут на серверах с приложениями. Сам сервер SnapCenter используется в качестве репозитория плагинов и для централизованного управления.
Ну и никто еще не отменял SnapManager'ы.

Вы жалуетесь на отсутствие данных, а почему не начать собирать данные краудсорсингом с это делает тот же Weather Underground с сетью персональных погодных станций? Все это дело возможно популязировать и построить большую сеть по России и/или СНГ.