- В этой теме 46 ответов, 11 участников, последнее обновление 4 года, 7 месяцев назад сделано
.
-
Сообщения
-
-
-
-
Дмитрий, никаких секретов подобной конфигурации нет. Нужна грамотная локальная команда инженеров и много денег акционеров.
Целевая топология строилась нами на базе уже имеющейся у нас практической экспертизы по данной платформе и целевых требований к конечному решению исходя из нашего исторического опыта использования оборудования 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 диску ресурс жизни не изменился даже на процент.
-
-
-
-
Хочу выразить своё уважение ко всем, кто приложил к этой системе руки/голову. Даже не мог представить, что это может быть у нас. Думал, что скорее в США (на основании распространенности систем).
Sever, и все остальные, примите мои поздравления! Это действительно большое достижение!
---As If, But Not---
-
-
-
график выше по латенси без привязки к iops совершенно не показателен
раз сказали А, то говорили бы уже и Б
практически любой сторадж может писать (естественно НЕ потоковой нагрузкой и большими блоками) с латенси порядка 0.2ms, если будет успевать сбрасывать свой write back cache, так что это возможно даже на HDD 🙂
понятно, что по чтению с HDD уже так не получиться, когда рабочее множество больше размера кеша на чтение
-
2Oleg: Зачем вам iopsы?
Данная система построена не по классической схеме сервер-сторадж. Ее топология сильно другая, система выполняет обе функции Одновременно – и вычислительную и функцию управления запоминающими устройствами. И делает она это довольно хорошо.Для понимание представьте себе такой утопический вариант. У вас есть большой Power сервер и есть большой навороченный сторадж DS8k, у которого основным центром управления является кластер из двух Power серверов мощностью поменьше.
Классическая схема взаимодействия Сервер – Сторадж используется всегда и везде. Для нее может быть иопсы и важны.
Наш вариант другой – мы выкидываем из стораджа 2 сервера управления и размещаем на их месте наш основной сервер.
Чувствуете разницу в топологии этих двух вариантов? Мы утопию реализовали на практике.
И еще… разница между 0.2мс и 50микросекундами довольно большая.
-
да хоть что выкиньте – необходимое кол-во дисковых операций для бизнес-приложения это не снизит
разница между 0.2мс и 2микросекундами еще больше 🙂 , но на графике выше – среднее ближе именно к 0.2мс (а к 1:00 и 1 мс, но тут можно угадать, что это из-за больших блоков при бэкапе)
и когда время отклика ниже этого среднего, то совершенно не очевидно – под какой нагрузкой и есть ли при этом вообще какое-то i/o
а зависимость iops и latency для любой дисковой всегда определяется подобной кривой
https://alikulov.me/blog/pictures/K2curve@2x.png
-
Пики в районе 2 часов отображают одновременное чтение и запись 10Тб информации. 10 ТБ читаются с дисков и 10 ТБ пишутся на эти же диски. Это единственный интервал времени, когда вы видите рост времени отклика дисковой системы. Это ночное время. В дневное время основной нагрузки с 8 до 18 уровень отклика стабилен и держится в районе 50-60 микросекунд. Просто наложения графиков от разных дней недели уводят зрительный фокус от стабильного уровня.
-
-
Да, в очередной раз вижу, что UNIX/AIX и IBM i это совершенно разные миры 🙂
Надеюсь, мы все понимаем, что мы все профессионалы каждый в своей специализации :)))
-
-
да хоть что выкиньте — необходимое кол-во дисковых операций для бизнес-приложения это не снизит
Вот тут вы жестоко ошибаетесь. Вся система спроектирована так, что бы максимально снизить число операций чтения и записи. Горячие данные размещаются в оперативной памяти после первого к ним обращения. Повторное чтение данных не приводит к генерации операции IO, так как нужная страница уже была подкачена ранее. Считайте, что система работает в режиме “in memory”. Основная активность в штатном режиме работы это операции записи и сброса “на диски” изменённых страниц. C этим боремся ещё лучше. Операции записи демпфируются буферами на запись дисковых контроллеров. Суммарный объем этого буфера составляет 384Гб.
Кэша на чтения у системы нет. Последние поколения SAS контроллеров ориентированы на SSD диски. Им кэш на чтение противопоказан, зато буфер на запись громадный. Кэширование на чтение эмулируется только при условии сохранения ранее записанных в буфер страниц и еще не выгруженных на диски. -
Наш вариант системы хранения на базе SSD с зеркальной защитой порвал в клочья предлагаемый нам вариант от IBM на базе флэш системы использущей на низком уровне RAID5. Прикольно, что наш вариант оказался в разы дешевле предлагаемого варианта от IBM.
А с чем конкретно и в какой конфигурации сравнивали ? FS900/v9000 ?
Какова была разница в иопсах/лэтенси ?
-
Сравнивали с DS8870, 16CPU P7+, 0.5TB кэш, прямое подключение через 16 портов 8Гбит, внутри было шесть полок HPFE(EXP30), сумммарно 180SSD по 400Гб, наружу было презентовано 192LUNа размером 282Гб. Фаза теста одновременной прокачки 10Тбайт в оба направления заняла мягко выражаясь неприлично большое время. После такого результата этот вариант нами больше не рассматривался. Не вытягивают стораджа под RAID5, а RAD10 на флешах никто не делает, такой опции просто не существует.
ЗЫ характеристики работы DS8K во всех остальных тестах базирующихся на дневной нагрузке показали вполне приемлемый результат. -
>> Сравнивали с DS8870, 16CPU P7+, 0.5TB кэш
Жаль, что не было сравнения с FlashSystem. Время отклика для FS (без SVC, т.е. не V) кардинально отличается от восьмитысячника.
>> И еще… разница между 0.2мс и 50микросекундами довольно большая
50 микросекунд – это нижний предел для enterprise SSD. Всё-таки, думаю, в среднем у вас больше. Тем интереснее было бы посмотреть в вашей среде на производительность bunch of ssd против FlashSystem.
>> Вот тут вы жестоко ошибаетесь. Вся система спроектирована так, что бы максимально снизить число операций чтения и записи. Горячие данные размещаются в оперативной памяти после первого к ним обращения. Повторное чтение данных не приводит к генерации операции IO, так как нужная страница уже была подкачена ранее
Вот тут не понял пафоса 😉 У меня каждая система так “спроектирована”, потому что это логика работы банального файлового кеша.
Но главный вопрос у меня другой: а что даёт такую нагрузку? Если я правильно вычислил клиента, то почему было принято решение о консолидации ИЛС, а не о сегментации? Они тесно связаны между собой (мне как раз казалось, что нет)?
-
>> Жаль, что не было сравнения с 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.>> Вот тут я не понял пафоса…
Я тоже не понял зачем вы это написали. Я привел аргумент без эмоций, причем не вам.
>> Но главный вопрос у меня другой: а что даёт такую нагрузку? Если я правильно вычислил клиента, то почему было принято решение о консолидации ИЛС, а не о сегментации? Они тесно связаны между собой (мне как раз казалось, что нет)?
Я не знаю что такое ИЛС. Меня не надо вычислять.
-
-
2Oleg: Зачем вам iopsы?
Данная система построена не по классической схеме сервер-сторадж.Я не Олег, но в данном случае вы наводите тень на плетень.
То, что у вас кеш (8Тб) составляет половину (!) от потенциально хранимой информации в пике (у вас ведь не все зазеркалированые 16Тб дисков забиты, вы ж купили на вырост, правильно?) – не означает, что здесь нет storage. Точно также локальность хранилища и то, что это DADS, не означает, что его нет вообще.
Мне как раз кажется, что у вас во время работы бОльшая часть базы (если не вся) умещается в памяти. Поэтому и интересны значения IOPS. Мне кажется, они будут небольшие. Косвенным образом это подтверждается тем, что вас полностью устроила работа DS8K на дневной нагрузке.
-
-
>> но ей приходится нести заметные накладные расходы, так как для нее привычный размер 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-ы, от физики то никуда не денешься.
-
-
-
-
Сравнивали с DS8870, 16CPU P7+, 0.5TB кэш, прямое подключение через 16 портов 8Гбит, внутри было шесть полок HPFE(EXP30), сумммарно 180SSD по 400Гб, наружу было презентовано 192LUNа размером 282Гб.
Спасибо. Тогда понятно почему оказалось “в разы дешевле” 🙂
-
Погуглил «ИЛС». Они же импортозамещаются…
Ага. На IBM System Z 😉
-
Погуглил «ИЛС». Они же импортозамещаются…
Ага. На IBM System Z
-
Пенсионный фонд мигрирует с IBM на «Эльбрус»
В тестировании принимали участие два сервера на платформе «Эльбрус» с четырьмя 4-ядерными процессорами с тактовой частотой 750 МГц, 96 ГБ оперативной памяти стандарта ЕСС DDR3 1066 MHz, шестью жесткими дисками Toshiba DT01ACA300 емкостью 3 ТБ каждый.
В качестве одной из главных вероятных причин сравнительно медленного функционирования выполнения действий с СУБД на платформе «Эльбрус» в ПФР указывают значительную оптимизация платформы IBM под СУБД DB2, которая глубоко интегрирована с операционной системой. Другая причина — специализированные возможности ввода-вывода платформы IBM по сравнению с неспециализированной подсистемой ввода-вывода платформы «Эльбрус». Также в фонде обращают внимание на недостаток оперативной памяти, что приводит к необходимости выполнения частых операций ввода-вывода (чтения с жестких дисков), на отсутствие специализированной СХД и на низкую тактовую частоту процессоров «Эльбрус».
-
-
Погуглил «ИЛС». Они же импортозамещаются…
Ага. На 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.”
-
Пенсионный фонд мигрирует с IBM на «Эльбрус»<span class=”tc-external”></span>
Табличка с результатами доставляет.
“Однако в фонде остались удовлетворены такими результатами, и намерены в начале 2017 г. докупить порядка 10 серверов на «Эльбрусах»” Главное не ехать, главное шашечки. -
-
е-мое. Для чего система? Биржа, банк, телеком? Что за скрытность?
Финансовая организация.
-
шестью жесткими дисками
7200RPM SATA
шестью! Карл! (с) :-)))
-
-
2 Sever: Впечатляющая конструкция. Вызывает уважение и некотоую зависть к авторам решения и причастным к реализации.
>> При полной потере системы мы переключаемся на другую систему в другом датацентре с полностью идентичными характеристиками, и на которой обеспечена консистентность и целостность данных на момент отказа основной системы.
Т.к. стораджей нет, значит никакой аппаратной репликации. Изменения журналируются. К чему вы в итоге пришли? Сторадж пул под журналирование отдельный или общий? CC включен? Какие-нибудь приёмы вроде journal caching используете?
-
Т.к. стораджей нет, значит никакой аппаратной репликации. Изменения журналируются. К чему вы в итоге пришли? Сторадж пул под журналирование отдельный или общий? CC включен? Какие-нибудь приёмы вроде journal caching используете?
В другом дата центре располагается полностью идентичная конфигурация сервера. Репликация изменений асинхронная, задействован MIMIX, используются remote журналы. Сетевые карты и вся сетевая инфраструктура – 10гигабит. На обеих системах только один ASP-(1)-системный. Вся нагрузка равномерно распределена по 320 дискам(160пар), каждый SSD – 775Гб. Полезное пространство пула – 124,000 Гб. Текущее заполнение пула в районе 50-65%%. СС не используется. Кэширование журналов в ведении функционального сопровождение, включен ли кэш, или выключен – это их зона ответственности. IMHO влияние кэша журналов при работе на SSD должно резко уменьшится. В обоих случаях уже основным фактором повышения производительности является аппаратный кэш дисковых контроллеров. По отчетам iDoctor средняя эффективность работы кэширования(работы буфера) дисковых контроллеров: на запись – 85%, на чтение – 10-15%%. Буфер на запись еще существенно удлиняет ресурс жизни SSD.
Никаких оптимизаций по размещению объектов в памяти не используем. Система сама определяет, что ей нужно в оперативной памяти, а что нет. Все 8ТБ постоянно чем то заняты. -
Для чего система? Биржа, банк, телеком?
Альфабанк.
-
-
Альфабанк
как раз об этом можно было и так догадаться
а вот что за система? не core banking же… 🙂
-
как раз об этом можно было и так догадаться а вот что за система? не core banking же…
У них Eqation, наверняка АБСку и крутят на этом мегасервере 🙂
-
наверняка АБСку и крутят на этом мегасервере
точно
я с ребрендированной AS/400 просто пересекался только в контексте Lotus-а, так что мысль про DB2 как-то обошла меня стороной 🙂
замена железа у них явно участилась – http://www.ibm.com/ru/events/presentations/fast2014/20_fast2014.pdf
причем, как видно из презентации – напускать тумана c I/O у них давняя традиция 🙂
-
-
статистика суммарного объема трафика чтения/записи за 4 часа
для OLTP она вообще непоказательна,
для OLAP – эти 45MBps на FC-порт тоже как бы ни о чем (как и меньше 800MBps суммарно), учитывая железо
-
… конечно “ни о чем”, причем, ваши расчеты нагрүзҡи на порт нужно пересчитать исходя из того, что портов на 5735 два 🙂
При начальңом проектировании топологии на базе двүх DS8800 использовался принцип максимальңого распаралеливания и балансировки трафика IO междү сервером и стораджами для снижения очередей и, как следствие, времени отклика на IO. Была нужна схема подключения, при ҡоторой ни при каких обстоятельствах невоможно возникңовение локальңой перегрузки ни на адаптерах со стороны сервера, ни на HBA на стораджах.
При последующем добавлении в топологию третьего DS8870 по полезному дисковому объему превышающему уже два имеющихся удалось частично удержать баланс на запись между тремя системами хранения.
-
Была нужна схема подключения, при ҡоторой ни при каких обстоятельствах невоможно возникңовение локальңой перегрузки
понимаю, для чудовищной нагрузки в 800MBps total это архисложно 🙂
-
-
- Для ответа в этой теме необходимо авторизоваться.
