Ну что же, по пункту 2, если убрать ключ xcopy, то около 100 мегабайт в секунду, если взять dd и увеличить блок, то около 400 мегабайт. Подозреваю, что можно делать в несколько потоков и будет быстрее. Что также касается и XCOPY — если разбить по адресам том на несколько кусков и делать XCOPY параллельно, то тоже может быть быстрее.
По пункту 5 сделал через md5sum, так и статья стала покороче :)
Кстати, по пункту 4 глянул статистику на СХД, размер блока был 16МБ, то есть запрос от ddpd в 32768 кусочков по 512 байт был собран в один IO запрос, так что наверное я тут с этим играться не буду, на данной СХД сомнительно что будет лучше.
1 и 2 — это не являлось целью исследований, использовалось то, что под рукой (InfiniBox) и скорость копирования без XCOPY не замерялась (можно замерить, но там много параметров будет влиять)
3 не хотелось отдавать определение количества итераций, а хотелось задать в явном виде, но можно сделать и как вы предлагаете
4 Ну скажем так, все считают размеры таким блоком, так было проще сделать, если скорость копирования не устраивает, то можно попробовать поиграть тут, но это не тот блок, которым происходит копирование, а указание СХД скопировать некоторое количество таких блоков
5 для того чтобы понять что файлы получились одинаковые. По идее надо бы чексумму считать, но на 1ТБ файле было как-то уже лень
Я сейчас может попробую еще поиграться и посмотреть по пунктам 2, 4 и 5
Пожалуйста! Если вы в этой теме недавно, то имеет смысл сходить и пооговорить с людьми кто плотно этим занимается. Раньше РСК и Т-Платформы были компетентны в России по этим вопросам.
Для вычислительного кластера от СХД обычно не требуется enterprise надежность и функционал, поэтому там обычно немного другие производители, типа Panasas и DDN. У DDN, кстати, был IB наружу раньше.
По сравнению с XIV архитектура совсем другая, там был grid, вот в плане удобства управления да, хотя интерфейс не очень похож внешне.
Да, начальный объем большой, но тут уж кому сколько надо. Насчет еще одного шкафа — есть варианты, можно и в существующий поставить, таких инсталляций довольно много.
В каком именно случае? При разрыве фабрик FC все работает и VMFS read/write, при разрыве IP (репликация) тоже все работает. Если есть разрыв по IP (репликация), то не основная сторона просто не доступна, а на основной все продолжает работать. Это сделано чтобы не было split brain.
Если репликационный линк есть, то СХД будет поддерживать обе копии одинаковыми, рассогласования не будет, операции записи будут подтверждаться только после записи на два массива. Если связь совсем разорвана, то будет доступна для работы копия, которая была выбрана приоритетной при настройке. После восстановления связи копии отсинхронизируются.
Тут скорее этот вариант — цитата из ссылки «гику стало интересно, какой провайдер с его точки зрения лучше и он потратил время, заказал услуги у разных, попользовался и сравнил. Это лучший вариант и даже если такие обзоры не очень технически корректны — всегда приятно их читать и учитывать при совершенствовании сервисов»
Тут скорее проблема не в том что они есть или нет, а в том что технический специалист должен это в принципе знать (как минимум в рамках конкурентного анализа) и учитывать как этот (если есть), так и другие факторы (garbage collection, например) при расчетах
Обычно разработка работает от обратного, оценивается возможный рост продаж от реализации фичи/интерфейса/продукта, оценивается время и сложность разработки и выбирается то, что можно быстро разработать и максимально увеличить объем продаж.
У HPC, как правило, нет требований к продвинутым фичам массива, основные критерии это производительность на поток+цена. Есть сектора HPC, где и функционал нужен получше и надежность (например медицина), но там и IB реже бывает.
При резервном копировании размер блока как правило в районе 1МБ, обычно задержки выше именно поэтому. Насчет Zabbix, я и темплейт сделал и скрипты для discovery и population, так что зовите в гости и все сделаем в лучшем виде. Потом можно будет все это и на GitHub запилить
По пункту 5 сделал через md5sum, так и статья стала покороче :)
3 не хотелось отдавать определение количества итераций, а хотелось задать в явном виде, но можно сделать и как вы предлагаете
4 Ну скажем так, все считают размеры таким блоком, так было проще сделать, если скорость копирования не устраивает, то можно попробовать поиграть тут, но это не тот блок, которым происходит копирование, а указание СХД скопировать некоторое количество таких блоков
5 для того чтобы понять что файлы получились одинаковые. По идее надо бы чексумму считать, но на 1ТБ файле было как-то уже лень
Я сейчас может попробую еще поиграться и посмотреть по пунктам 2, 4 и 5
По сравнению с XIV архитектура совсем другая, там был grid, вот в плане удобства управления да, хотя интерфейс не очень похож внешне.
kb.vmware.com/s/article/71047
support.infinidat.com/hc/en-us/articles/360002108357-Active-Active-replication
community.hpe.com/t5/Around-the-Storage-Block/Fibre-Channel-The-lifeblood-of-storage-connectivity-in-the-data/ba-p/7046140
да, такое и мне вспоминается :)
У HPC, как правило, нет требований к продвинутым фичам массива, основные критерии это производительность на поток+цена. Есть сектора HPC, где и функционал нужен получше и надежность (например медицина), но там и IB реже бывает.
В случае F2000, как у Онланты, просто от каждого контроллера SAS кабель идет к каждой полке, собственно все!