Largest IBM i partition in the world

Главная Форумы IBM i (OS/400) Largest IBM i partition in the world

  • В этой теме 46 ответов, 11 участников, последнее обновление 3 года назад сделано Sever.
Просмотр 35 веток ответов
  • Автор
    Сообщения
    • #39296
      Sever
      Участник

      IBM признала нашу инсталляцию крупнейшей во всем мире.
      Самая мощная и высоконагруженная система под управлением ОС IBMi работает в России.
      null

    • #39297
      Дмитрий
      Участник

      Поздравляю, круто!

      А сможешь с коллегами поделиться секретами настройки такой громадины? Обязательно должны быть тонкости, такие как правильное размещение адаптеров, DSO и тд.

    • #39298
      Sever
      Участник

      Дмитрий, никаких секретов подобной конфигурации нет. Нужна грамотная локальная команда инженеров и много денег акционеров.

      Целевая топология строилась нами на базе уже имеющейся у нас практической экспертизы по данной платформе и целевых требований к конечному решению исходя из нашего исторического опыта использования оборудования IBM для ОС IBMi.
      При построении системы наши цели были следующими:
      – максимальная возможная производительность IO;
      – максимально возможная защита от сбоев на уровне оборудования и защита от инцидентов потери электропитания отдельными элементами или блоками системы.

      1. Производительность IO решалась отказом от использования HDD, как класса конечных устройств хранения информации, и переходом на SSD. Для IBM i неважно какие у тебя процессоры, важно то, – каково время отклика системы хранения, важно – какая у тебя топология ввода вывода и какие устройства хранения используются. При переходе на SSD паралельно был принят за аксиому (для данной системы) отказ от использования защиты RAID для конечных устройств на уровне контроллеров ввода/вывода. Мы вернулись к зеркальной защите конечных устройств хранения на уровне ОС. При лавинной активности IO на запись вычисление parity для RAID является узким местом. При зеркальной защите конечные устройства работают в режиме JBOD, контролеры тупо пищут блоки данных и не отвлекаются на вычисление parity. Это было выявлено нами много лет назад на первых тестовых экспериментах c SSD и это было подтвержено при тестирование в лаборатории IBM в этом году. Наш вариант системы хранения на базе SSD с зеркальной защитой порвал в клочья предлагаемый нам вариант от IBM на базе флэш системы использущей на низком уровне RAID5. Текущее время отклика для операций записи в штатном режиме у нас равно 50 микросекунд. Ни одна из имеющихся стистем хранения в мире не может обеспечить подобных значений. Прикольно, что наш вариант оказался в разы дешевле предлагаемого варианта от IBM.
      Секрета по размещению контроллеров тоже нет. Просто дисковых контроллеров должно быть столько, сколько вообще разрешено устанавливать в блоки ввода вывода. У нас их ровно 32 штуки. Это максимум для 4х блоков расширения EMX0.

      2. Защита от сбоев отдельных элементов или блоков реализована следующим образом:
      – обеспечена защита от сбоя отдельного SSD диска;
      – обеспечена защита от сбоя отдельного контроллера IO;
      – обеспечена защита от сбоя или потери элетропитания отдельного блока расширения EMX0, на котором располагается 8 контроллеров и 80 SSD;
      – обеспечивается работа системы при полном обесточивании двух блоков EMX0, находящихся в одной стойке (16 контроллеров и 160 SSD);

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

      Ко всему прочему мы имеем инструмент контроля за ресурсом жизни SSD. Нам его никто официально не предоставлял, мы его нашли сами в дебрях ОС IBM i, он измеряется в процентах. За полгода с момента запуска системы в продуктив ни по одному SSD диску ресурс жизни не изменился даже на процент.

    • #39299
      Дмитрий
      Участник

      Спасибо!

    • #39300
      Sever
      Участник

      Disk Response times

    • #39301
      Sever
      Участник

      CPU utilization for the partition over a week.
      CPU over week

    • #39303
      _KIRill
      Хранитель

      Хочу выразить своё уважение ко всем, кто приложил к этой системе руки/голову. Даже не мог представить, что это может быть у нас. Думал, что скорее в США (на основании распространенности систем).

      Sever, и все остальные, примите мои поздравления! Это действительно большое достижение!

      ---As If, But Not---

    • #39304
      Demetrio
      Участник

      А что молотилка молотит? Обсчет гидродинамических процессов? Погода?

      • #39305
        wpg
        Участник

        Попробую угадать… не Power а Z, и не i а Linux, и не крупнейшая в мире, а наикрупнейшая в галактике. Обсчитывают аэродинамику межконтинентальных гиперзвуковых газонокосилок. :)))

    • #39306
      Oleg
      Участник

      график выше по латенси без привязки к iops совершенно не показателен

      раз сказали А, то говорили бы уже и Б

      практически любой сторадж может писать (естественно НЕ потоковой нагрузкой и большими блоками) с латенси порядка 0.2ms, если будет успевать сбрасывать свой write back cache, так что это возможно даже на HDD 🙂

      понятно, что по чтению с HDD уже так не получиться, когда рабочее множество больше размера кеша на чтение

       

    • #39308
      Sever
      Участник

      2Oleg: Зачем вам iopsы?
      Данная система построена не по классической схеме сервер-сторадж. Ее топология сильно другая, система выполняет обе функции Одновременно – и вычислительную и функцию управления запоминающими устройствами. И делает она это довольно хорошо.

      Для понимание представьте себе такой утопический вариант. У вас есть большой Power сервер и есть большой навороченный сторадж DS8k, у которого основным центром управления является кластер из двух Power серверов мощностью поменьше.

      Классическая схема взаимодействия Сервер – Сторадж используется всегда и везде. Для нее может быть иопсы и важны.

      Наш вариант другой – мы выкидываем из стораджа 2 сервера управления и размещаем на их месте наш основной сервер.

      Чувствуете разницу в топологии этих двух вариантов? Мы утопию реализовали на практике.

      И еще… разница между 0.2мс и 50микросекундами довольно большая.

      • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
      • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
    • #39311
      Oleg
      Участник

      да хоть что выкиньте – необходимое кол-во дисковых операций для бизнес-приложения это не снизит

      разница между 0.2мс и 2микросекундами еще больше 🙂 , но на графике выше – среднее ближе именно к 0.2мс (а к 1:00 и 1 мс, но тут можно угадать, что это из-за больших блоков при бэкапе)

      и когда время отклика ниже этого среднего, то совершенно не очевидно – под какой нагрузкой и есть ли при этом вообще какое-то i/o

      а зависимость iops и latency для любой дисковой всегда определяется подобной кривой

      https://alikulov.me/blog/pictures/K2curve@2x.png

       

      • #39313
        Sever
        Участник

        Пики в районе 2 часов отображают одновременное чтение и запись 10Тб информации. 10 ТБ читаются с дисков и 10 ТБ пишутся на эти же диски. Это единственный интервал времени, когда вы видите рост времени отклика дисковой системы. Это ночное время. В дневное время основной нагрузки с 8 до 18 уровень отклика стабилен и держится в районе 50-60 микросекунд. Просто наложения графиков от разных дней недели уводят зрительный фокус от стабильного уровня.

    • #39312
      Дмитрий
      Участник

      Да, в очередной раз вижу, что UNIX/AIX и IBM i это совершенно разные миры 🙂

      Надеюсь, мы все понимаем, что мы все профессионалы каждый в своей специализации :)))

      • #39314
        Sever
        Участник

        Ага, абсолютно перпендикулярные миры 🙂

    • #39315
      Sever
      Участник

      да хоть что выкиньте — необходимое кол-во дисковых операций для бизнес-приложения это не снизит

      Вот тут вы жестоко ошибаетесь. Вся система спроектирована так, что бы максимально снизить число операций чтения и записи. Горячие данные размещаются в оперативной памяти после первого к ним обращения. Повторное чтение данных не приводит к генерации операции IO, так как нужная страница уже была подкачена ранее. Считайте, что система работает в режиме “in memory”. Основная активность в штатном режиме работы это операции записи и сброса “на диски” изменённых страниц. C этим боремся ещё лучше. Операции записи демпфируются буферами на запись дисковых контроллеров. Суммарный объем этого буфера составляет 384Гб.
      Кэша на чтения у системы нет. Последние поколения SAS контроллеров ориентированы на SSD диски. Им кэш на чтение противопоказан, зато буфер на запись громадный. Кэширование на чтение эмулируется только при условии сохранения ранее записанных в буфер страниц и еще не выгруженных на диски.

      • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
    • #39318
      barmaley
      Участник

      Наш вариант системы хранения на базе SSD с зеркальной защитой порвал в клочья предлагаемый нам вариант от IBM на базе флэш системы использущей на низком уровне RAID5. Прикольно, что наш вариант оказался в разы дешевле предлагаемого варианта от IBM.

      А с чем конкретно и в какой конфигурации сравнивали ?  FS900/v9000 ?

      Какова была разница в  иопсах/лэтенси ?

       

       

    • #39319
      Sever
      Участник

      Сравнивали с DS8870, 16CPU P7+, 0.5TB кэш, прямое подключение через 16 портов 8Гбит, внутри было шесть полок HPFE(EXP30), сумммарно 180SSD по 400Гб, наружу было презентовано 192LUNа размером 282Гб. Фаза теста одновременной прокачки 10Тбайт в оба направления заняла мягко выражаясь неприлично большое время. После такого результата этот вариант нами больше не рассматривался. Не вытягивают стораджа под RAID5, а RAD10 на флешах никто не делает, такой опции просто не существует.
      ЗЫ характеристики работы DS8K во всех остальных тестах базирующихся на дневной нагрузке показали вполне приемлемый результат.

      • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
      • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
    • #39325
      Alex
      Участник

      >> Сравнивали с DS8870, 16CPU P7+, 0.5TB кэш

      Жаль, что не было сравнения с FlashSystem. Время отклика для FS (без SVC, т.е. не V) кардинально отличается от восьмитысячника.

      >> И еще… разница между 0.2мс и 50микросекундами довольно большая

      50 микросекунд – это нижний предел для enterprise SSD. Всё-таки, думаю, в среднем у вас больше. Тем интереснее было бы посмотреть в вашей среде на производительность bunch of ssd против FlashSystem.

      >> Вот тут вы жестоко ошибаетесь. Вся система спроектирована так, что бы максимально снизить число операций чтения и записи. Горячие данные размещаются в оперативной памяти после первого к ним обращения. Повторное чтение данных не приводит к генерации операции IO, так как нужная страница уже была подкачена ранее

      Вот тут не понял пафоса 😉 У меня каждая система так “спроектирована”, потому что это логика работы банального файлового кеша.

      Но главный вопрос у меня другой: а что даёт такую нагрузку? Если я правильно вычислил клиента, то почему было принято решение о консолидации ИЛС, а не о сегментации? Они тесно связаны между собой (мне как раз казалось, что нет)?

      • Ответ изменён 3 года, 1 месяц назад пользователем Alex.
      • #39335
        Sever
        Участник

        >> Жаль, что не было сравнения с FlashSystem. Время отклика для FS (без SVC, т.е. не V) кардинально отличается от восьмитысячника.

        Относительно FS900. Хорошая штука, тестировали локально. Вполне пригодна для небольших систем. Но у нее есть один недостаток, который нужно иметь ввиду при использовании ее для систем с ОС IBM i. Эти системы презентуют наружу свои ресурсы секторами в 4096 байт. IBM i научилась работать со стораждами с таким форматом сектора, но ей приходится нести заметные накладные расходы, так как для нее привычный размер 4kсектора должен быть равен 4224 байтам. Для систем с интенсивно меняющимися данными эти накладные расходы очень заметны.
        Для AIXовых систем FS900 лучшее, что есть на рынке.

        >> 50 микросекунд — это нижний предел для enterprise SSD. Всё-таки, думаю, в среднем у вас больше. Тем интереснее было бы посмотреть в вашей среде на производительность bunch of ssd против FlashSystem.

        Тут вы ошибаетесь. SSD в принципе не могут работать с таким откликом. Минимальный отклик у SSD диска лежит в районе 100-115 микросекунд. У любого аллфлеша эта величина аналогична. Быстрее нельзя, медленнее можно.
        50 миллисекунд реализуются за счет того, что сигнал о завершении операции записи выдается серверу немедленно, а блоки данных все еще лежат в памяти у локального SAS контроллера. 50 миллисекунд это благодаря быстрому контроллеру, которому даже не надо ксорить данные для организации RAID.

        >> Вот тут я не понял пафоса…

        Я тоже не понял зачем вы это написали. Я привел аргумент без эмоций, причем не вам.

        >> Но главный вопрос у меня другой: а что даёт такую нагрузку? Если я правильно вычислил клиента, то почему было принято решение о консолидации ИЛС, а не о сегментации? Они тесно связаны между собой (мне как раз казалось, что нет)?
        Я не знаю что такое ИЛС. Меня не надо вычислять.

        • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
    • #39327
      Alex
      Участник

      2Oleg: Зачем вам iopsы?
      Данная система построена не по классической схеме сервер-сторадж.

      Я не Олег, но в данном случае вы наводите тень на плетень.

      То, что у вас кеш (8Тб) составляет половину (!) от потенциально хранимой информации в пике (у вас ведь не все зазеркалированые 16Тб дисков забиты, вы ж купили на вырост, правильно?) – не означает, что здесь нет storage. Точно также локальность хранилища и то, что это DADS, не означает, что его нет вообще.

      Мне как раз кажется, что у вас во время работы бОльшая часть базы (если не вся) умещается в памяти. Поэтому и интересны значения IOPS. Мне кажется, они будут небольшие. Косвенным образом это подтверждается тем, что вас полностью устроила работа DS8K на дневной нагрузке.

      • #39337
        Sever
        Участник

        Сформулируйте пожалуйста вопрос в понятной форме, если он у вас есть. Я просто затрудняюсь в понимании.
        Или вы тоже хотите узнать значение iops? Но зачем?

      • #39339
        Alex
        Участник

        >> но ей приходится нести заметные накладные расходы, так как для нее привычный размер 4kсектора должен быть равен 4224 байтам

        Интересно. И вместе с тем ужасно, конечно 😉

        >> Тут вы ошибаетесь. SSD в принципе не могут работать с таким откликом. Минимальный отклик у SSD диска лежит в районе 100-115 микросекунд

        Достаточно открыть спеку на любой современный enterprise ssd (от интела, например, посмотрите), чтобы увидеть, что ваши представления отстали от жизни. ~50/60 сейчас minimal latency для read/write.

        >> сигнал о завершении операции записи выдается серверу немедленно, а блоки данных все еще лежат в памяти у локального SAS контроллера

        … как и у любого другого storage-а с включенным write cache.

        >> Я тоже не понял зачем вы это написали. Я привел аргумент без эмоций, причем не вам.

        А здесь отвечать можно только на лично адресованное? Простите, не знал, в следующий раз обязательно спрошу у вас разрешения. Написал я это по простой причине: я не понял, чем банальный механизм файлового кеширования заслужил столь подробного описания. Показалось, что вы его описали как killer-фичу, что ли. Да и не показалось, вы так и сделали.

        >> Я не знаю что такое ИЛС. Меня не надо вычислять.

        Я вас помню исключительно визуально со старого аикспортала. Мне почему-то казалось, что у нас самая большая инсталляция iSeries в ПФР. Ну нет так нет.

        >> Сформулируйте пожалуйста вопрос в понятной форме, если он у вас есть. Я просто затрудняюсь в понимании.
        Или вы тоже хотите узнать значение iops? Но зачем?

        Это не вопрос, а комментарии к более чем спорным утверждениям о том, что у вас какая-то “особенная” архитектура. И они не столько для вас, сколько для остальных. Вам iops-ы не важны, потому что у вас получилось фактически in-memory решение. Если бы количество памяти сервера было не 8Тб, а 1Тб или 512Гб – внезапно выяснилось, что и на DASD тоже надо прикидывать iops-ы, от физики то никуда не денешься.

        • #39340
          Sever
          Участник

          Продолжать диалог с вами “ни о чем” мне не хочется.
          Если вдруг появятся конкретные вопросы – задавайте.

    • #39338
      Sever
      Участник

      2Alex: Погуглил “ИЛС”.
      Как вам вообще могло такое в голову прийти?
      Они же импортозамещаются…

    • #39341
      barmaley
      Участник

      Сравнивали с DS8870, 16CPU P7+, 0.5TB кэш, прямое подключение через 16 портов 8Гбит, внутри было шесть полок HPFE(EXP30), сумммарно 180SSD по 400Гб, наружу было презентовано 192LUNа размером 282Гб.  

      Спасибо. Тогда понятно почему оказалось “в разы дешевле” 🙂

    • #39342
      barmaley
      Участник

      Погуглил «ИЛС».  Они же импортозамещаются…

      Ага. На IBM System Z  😉

    • #39343
      Sever
      Участник

      Погуглил «ИЛС». Они же импортозамещаются…

      Ага. На IBM System Z

      Нет. Они решили перейти на отечественное.

      • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
      • #39346
        Sever
        Участник

        Пенсионный фонд мигрирует с IBM на «Эльбрус»

        В тестировании принимали участие два сервера на платформе «Эльбрус» с четырьмя 4-ядерными процессорами с тактовой частотой 750 МГц, 96 ГБ оперативной памяти стандарта ЕСС DDR3 1066 MHz, шестью жесткими дисками Toshiba DT01ACA300 емкостью 3 ТБ каждый.

        В качестве одной из главных вероятных причин сравнительно медленного функционирования выполнения действий с СУБД на платформе «Эльбрус» в ПФР указывают значительную оптимизация платформы IBM под СУБД DB2, которая глубоко интегрирована с операционной системой. Другая причина — специализированные возможности ввода-вывода платформы IBM по сравнению с неспециализированной подсистемой ввода-вывода платформы «Эльбрус». Также в фонде обращают внимание на недостаток оперативной памяти, что приводит к необходимости выполнения частых операций ввода-вывода (чтения с жестких дисков), на отсутствие специализированной СХД и на низкую тактовую частоту процессоров «Эльбрус».

        • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
    • #39349
      barmaley
      Участник

      Погуглил «ИЛС». Они же импортозамещаются…

      Ага. На IBM System Z

      Нет. Они решили перейти на отечественное.<span class=”tc-external”></span>

      Что-то не получается ссылку вставить. В АИС ПФР-2, которая должна быть сдана в следующем году там будет :

      “Каждый ЦОД предлагается строить из двух основных контуров: контур мейнфреймов IBM и контур серверов RISC и x86. Первая технологическая площадка ЦОДов, предназначенная для разработки и прототипирования АИС ПФР-2, включает, в частности, вычислительный комплекс на базе мейнфрейма IBM zEnterprise и системы IBM zEnterprise BladeCenter Extension, СХД IBM, аналитические системы обработки данных IBM Puredata System for Analytics, а также контур blade-серверов IBM HS23 и IBM HX5.”

    • #39350
      barmaley
      Участник

      Пенсионный фонд мигрирует с IBM на «Эльбрус»<span class=”tc-external”></span>

      Табличка с результатами доставляет.
      “Однако в фонде остались удовлетворены такими результатами, и намерены в начале 2017 г. докупить порядка 10 серверов на «Эльбрусах»” Главное не ехать, главное шашечки.

    • #39351
      Demetrio
      Участник

      е-мое. Для чего система? Биржа, банк, телеком? Что за скрытность?

    • #39352
      Sever
      Участник

      е-мое. Для чего система? Биржа, банк, телеком? Что за скрытность?

      Финансовая организация.

    • #39356
      Oleg
      Участник

      шестью жесткими дисками

      7200RPM SATA

      шестью! Карл! (с) :-)))

       

       

      • Ответ изменён 3 года, 1 месяц назад пользователем _KIRill.
      • #39359
        Sever
        Участник

        Цена диска – сто баксов, позиционируется как “для настольных компьютеров”
        Зато один сервер целиком для ПФР обойдется в цену от 1 до 2х миллионов рублей. Недорого.

        • Ответ изменён 3 года, 1 месяц назад пользователем Sever.
    • #39367
      pre
      Участник

      2 Sever: Впечатляющая конструкция. Вызывает уважение и некотоую зависть к авторам решения и причастным к реализации.

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

      Т.к. стораджей нет, значит никакой аппаратной репликации. Изменения журналируются. К чему вы в итоге пришли? Сторадж пул под журналирование отдельный или общий? CC включен? Какие-нибудь приёмы вроде journal caching используете?

    • #39368
      Sever
      Участник

      Т.к. стораджей нет, значит никакой аппаратной репликации. Изменения журналируются. К чему вы в итоге пришли? Сторадж пул под журналирование отдельный или общий? CC включен? Какие-нибудь приёмы вроде journal caching используете?

      В другом дата центре располагается полностью идентичная конфигурация сервера. Репликация изменений асинхронная, задействован MIMIX, используются remote журналы. Сетевые карты и вся сетевая инфраструктура – 10гигабит. На обеих системах только один ASP-(1)-системный. Вся нагрузка равномерно распределена по 320 дискам(160пар), каждый SSD – 775Гб. Полезное пространство пула – 124,000 Гб. Текущее заполнение пула в районе 50-65%%. СС не используется. Кэширование журналов в ведении функционального сопровождение, включен ли кэш, или выключен – это их зона ответственности. IMHO влияние кэша журналов при работе на SSD должно резко уменьшится. В обоих случаях уже основным фактором повышения производительности является аппаратный кэш дисковых контроллеров. По отчетам iDoctor средняя эффективность работы кэширования(работы буфера) дисковых контроллеров: на запись – 85%, на чтение – 10-15%%. Буфер на запись еще существенно удлиняет ресурс жизни SSD.
      Никаких оптимизаций по размещению объектов в памяти не используем. Система сама определяет, что ей нужно в оперативной памяти, а что нет. Все 8ТБ постоянно чем то заняты.

    • #39525
      navion
      Участник

      Для чего система? Биржа, банк, телеком?

      Альфабанк.

    • #39547
      Grigori Astanovski
      Участник

      Интересно… у нас график в точности наоборот. Близкая к максимальной загрузка в время ночного EoD, а днём так, вхолостую почти.

    • #39549
      Oleg
      Участник

      Альфабанк

      как раз об этом можно было и так догадаться

      а вот что за система? не core banking же… 🙂

    • #39556
      navion
      Участник

      как раз об этом можно было и так догадаться а вот что за система? не core banking же…

      У них Eqation, наверняка АБСку и крутят на этом мегасервере 🙂

      • Ответ изменён 3 года назад пользователем navion.
    • #39559
      Oleg
      Участник

      наверняка АБСку и крутят на этом мегасервере

      точно

      я с ребрендированной AS/400 просто пересекался только в контексте Lotus-а, так что мысль про DB2 как-то обошла меня стороной 🙂

      замена железа у них явно участилась – http://www.ibm.com/ru/events/presentations/fast2014/20_fast2014.pdf

      причем, как видно из презентации – напускать тумана c I/O у них давняя традиция 🙂

      • #39561
        Sever
        Участник

        это не туман, на картине была представлена статистика суммарного объема трафика чтения/записи за 4 часа через каждый из 24х адаптеров FC5735. Плюс наложен соответствующий график времени отлика.

    • #39563
      Oleg
      Участник

      статистика суммарного объема трафика чтения/записи за 4 часа

      для OLTP она вообще непоказательна,

      для OLAP – эти 45MBps на FC-порт тоже как бы ни о чем (как и меньше 800MBps суммарно), учитывая железо

      • Ответ изменён 3 года назад пользователем Oleg.
      • Ответ изменён 3 года назад пользователем Oleg.
    • #39566
      Sever
      Участник

      … конечно “ни о чем”, причем, ваши расчеты нагрүзҡи на порт нужно пересчитать исходя из того, что портов на 5735 два 🙂

      При начальңом проектировании топологии на базе двүх DS8800 использовался принцип максимальңого распаралеливания и балансировки трафика IO междү сервером и стораджами для снижения очередей и, как следствие, времени отклика на IO. Была нужна схема подключения, при ҡоторой ни при каких обстоятельствах невоможно возникңовение локальңой перегрузки ни на адаптерах со стороны сервера, ни на HBA на стораджах.

      При последующем добавлении в топологию третьего DS8870 по полезному дисковому объему превышающему уже два имеющихся удалось частично удержать баланс на запись между тремя системами хранения.

      • Ответ изменён 3 года назад пользователем Sever.
      • Ответ изменён 3 года назад пользователем Sever.
    • #39569
      Oleg
      Участник

      Была нужна схема подключения, при ҡоторой ни при каких обстоятельствах невоможно возникңовение локальңой перегрузки

      понимаю, для чудовищной нагрузки в 800MBps total это архисложно 🙂

      • #39570
        Sever
        Участник

        Надеюсь, что вопрос о Проблемах шаманизма среди народов крайнего Севера исчерпан и вы удовлетворены.

Просмотр 35 веток ответов
  • Для ответа в этой теме необходимо авторизоваться.