Comments 8
Хотите я вам расскажу про ночной кошмар любой системы, у которой 95% кешировано?
Допустим, в ДЦ пропало питание без предупреждения. Допустим, у нас хранилка на 100Тб, утилизация около 30%. Там лежат виртуалки. Допустим, компрессия и дедупликация даёт нам 50% экономии (это означает, что при полной дедупликации у нас получается 60% утилизации, всё ещё хорошо). Допустим, средний том 30Гб. Это означает, что на СХД 2000 виртуальных машин.
И вот у нас старт. СХД прогревается, гипервизоры прогреваются и начинают стартовать. Благодаря дедупликации данные ОС в горячем кеше и всё идёт отлично. Запускается ~1500 виртуальных машин, и вот они доходят до этапа монтирования файловой системы. А там:
а) Не было проверок уже больше полугода.
б) Unclean shutdown
И вот у вас 1500 fsck шуршат по диску. В режиме random read, который гарантировано уникальный для каждой виртуалки. Ice cold random read. От 1500 виртуалок. И ещё 500 на подходе.
Диски в полном ауте, кеши пусты, пока… пока не случается 300с таймаут и первая виртуалка решает, что если ей блочное устройство не ответило за 300с, значит оно не ответит никогда, и не переводит файловую систему в RO режим из-за ошибки.… Если бы не опция паник, после чего виртуалка перезагружается. И снова видит unclean shutdown...
1500 виртуалок запаниковало и ушло в ребут. 500 на подходе.
95% кеширования означает, что оставшиеся 5% система жидко обсирается. Если это единичные всплески, с этим можно жить. Но кроме correlated errors ещё бывает и correlated load, и вот тут-то и наступает отрицательный рост стабильности, сопровождающийся хлопком аптайма.
Вы не можете сделать prefetch для серверов, которые первый раз в жизни задумались про fsck. Плюс, "оптимизация очередей" работает в очень узкой ситуации (например, 10 конкурентных последовательных чтений).
Каждый fsck — это прыжки по диску (по всему диску!), а у вас 30% утилизация, т.е. у вас 1500 очередей, каждая из которых прыгает по десяткам гигабайт, а вместе они прыгают по всему provisioned space, причём (подло) только по записанным данным.
Если вы научитесь предсказывать неожиданное чтение (ice reads), то можно завязывать с СХД и смело идти на фондовые рынки.
Нимбл, да и все, LFS-based массивы физически записывают пришедшие данные подряд, а не на место, соответствующее физическому LBA (оперируя логическим LBA), поэтому вероятность поднять префетчем нужные данные, на мой взгляд, достаточно высока. Да и у просто thin provisioned, даже без LFS, новые данные будут физически записываться подряд.
Но да, надо будет как-то попробовать такой тест.
Я просто видел, что становится с оптимистично прогретыми СХД после перезагрузок такого характера. Ничего хорошего. После 2-3 циклов приходят админы, ставят все виртуалки в shutdown, и начинают запускать их пачками. Начинается всякая консольная магия, типа "взять список всех не запущенных, и группами по 30 штук", а потом охота за теми, которые remount RO сделали вместо паники.
Главное, при наличии кешей всегда знать ответ на то, что будет при ice reads. Рассказы вендоров про то, что у них суперкеширование и "такого не будет" рассеиваются очень просто. Если у них 95% кешированных чтений, то есть 5% не кешированных. Это в average. Дальше вопрос: может ли случиться коррелированный сценария обращения к некешированным данным? Ответ, да, может. На любой кеш может быть атака (человеческая или стихийная) и любой кеш по очевидным причинам может быть пропущен (потому что если кеш 10% от медленного слоя, то где-то там (при 50% утилизации) есть 80% данных, чтение которых идёт мимо кеша).
И вопрос в том, как к этому готовиться, а не в том, что какой-то магический вендор может кешом в 10Тб обслужить 100Тб данных.
во первых: про систему «midrange» уровня. 2000 виртуалок многовато для одной такой системы. Пару сотен – в самый раз. Как Вы видели, мы тестили 480 потока с профилем 60/40, результат отклика был ~ 4 мс. Nimble может объединится в кластер (причем модели СХД не обязательно могут быть одинаковы) с суммированием производительности, т.е. 4 таких системы с нагрузкой в 4*480=1920 потоков при 60/40 уложатся в отклик до ~4 мс.
во вторых: как я писал, первые тесты по ошибке были сделаны без кеширования (без участия SSD кеша на чтения, на голых HDD дисках). При 384 потоках получилось 94k IOPS 4k и отклик в ~5мс при 100% чтении. Что будет если увеличить это до 1500 потоков (без кеширования) – вопрос пока открытый. Если доберутся руки ради эксперимента попробую сделать. Делаю ставку что отклик будет в районе 10…20мс.
Хотелось бы хотя бы в общих чертах понять порядок цен, например относительно 3PAR 8200
Тестирование производительности и краткий обзор HPE Nimble Storage Adaptive Flash HF60