Largest IBM i partition in the world


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

В этой теме 46 ответов, 11 участников, последнее обновление  Sever 11 мес., 1 неделя назад.

  • Автор
    Сообщения
  • #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микросекундами довольно большая.

    • Ответ изменён 1 год назад пользователем  Sever.
    • Ответ изменён 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 диски. Им кэш на чтение противопоказан, зато буфер на запись громадный. Кэширование на чтение эмулируется только при условии сохранения ранее записанных в буфер страниц и еще не выгруженных на диски.

    • Ответ изменён 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 во всех остальных тестах базирующихся на дневной нагрузке показали вполне приемлемый результат.

    • Ответ изменён 1 год назад пользователем  Sever.
    • Ответ изменён 1 год назад пользователем  Sever.
  • #39325

    Alex
    Участник

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

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

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

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

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

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

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

    • Ответ изменён 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.

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

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

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

      • Ответ изменён 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

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

    • Ответ изменён 1 год назад пользователем  Sever.
    • #39346

      Sever
      Участник

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

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

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

      • Ответ изменён 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

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

     

     

    • Ответ изменён 1 год назад пользователем  _KIRill.
    • #39359

      Sever
      Участник

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

      • Ответ изменён 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, наверняка АБСку и крутят на этом мегасервере 🙂

    • Ответ изменён 11 мес., 2 нед. назад пользователем  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 суммарно), учитывая железо

    • Ответ изменён 11 мес., 1 неделя назад пользователем  Oleg.
    • Ответ изменён 11 мес., 1 неделя назад пользователем  Oleg.
  • #39566

    Sever
    Участник

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

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

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

    • Ответ изменён 11 мес., 1 неделя назад пользователем  Sever.
    • Ответ изменён 11 мес., 1 неделя назад пользователем  Sever.
  • #39569

    Oleg
    Участник

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

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

    • #39570

      Sever
      Участник

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

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