Взгляд на эволюцию резервного копирования. Взято вот тут http://www.nten.org
Давно ведутся споры между сторонниками традиционного подхода к резервному копированию и теми, кто ищет новые способы защиты данных, более удобные с точки зрения архитектуры используемых систем хранения.
Сейчас этот спор обострился, поскольку в течение небольшого времени в мире резко выросло разнообразие типов систем хранения. Некоторые из них требуют изменить подходы к привычным задачам по эксплуатации и обеспечению доступности, включая резервное копирование, о котором я хочу повести речь.
Статья переехала в Блог EMC на Хабре.
Есть вопрос, на основе чего получилось время выполнения РК 36ТБ?
Fargon, время копирования =объем в МБ делить на скорость в МБ/сек. Для каждого уровня считаем время его бэкапа и складываем все вместе. Для нижнего уровня скорость бэкапа самая низкая — 40 мб/сек. 5мб/сек на один диск NLSAS.
Денис, а откуда берется цифра 5 мб/сек на один шпиндель NL-SAS? Эмпирически выведена? Тут еще я так понимаю должна быть зависимость и того, какой именно NL-SAS диск используется — 1, 2, 3, 4 или 6 Тб?
За статью спасибо. В самом деле заставляет задуматься.
Хороший вопрос. Я полез в VNX best practices, а там сейчас пишут характерную скорость 15 мб/сек с NLSAS диска. Правда оговариваются, что это скорость при «одновременном многопоточном чтении большими блоками». Я бы такую скорость для бэкапа не закладывал. Что касается 5МБ/сек с диска, то я ее рассчитал в нулевом приближении взяв быстродействие диска 80 IOPS и помножив на размер блока 64 КБ. Это типичная гранулярность при построении RAID. Эта цифра довольно хорошо соответствует наблюдению в реальных ситуациях, когда диски специально для тестов не «тюнят», и не нагружают синтетикой.
Денис, спасибо, полезно, я как раз делал эту ошибку — закладывал большие и медленные диски в нижний тир, не думаю о времени восстановления. Жду новых статей.
«взяв быстродействие диска 80 IOPS и помножив на размер блока 64 КБ»
это крайне странный размер блока для фулл бэкапа ;-), т.к. для данной нагрузки более типично потоковое чтение с размером блока от 256КБ
то есть для сферического коня в вакууме, все же будет порядка 80х256КБ=20MBps
в реальной жизни с одной рейд-группы на таких NL HDD вполне можно снимать порядка 150MBps
при чем, если мы говорим о прогретой СХД с 3-уровневым хранением, то на NL не будет сколь-нибудь заметного I/O, способного замедлить бэкап (т.к. это самый «холодный» уровень)
то есть все действительно печально, но не настолько драматично, как предполагает автор 😉
Олег, спасибо за комментарий. Тема не спроста про «подводные камни». Чтение 256КБ с файловой системы или БД далеко не всегда приводит к чтению 256КБ с физического диска. Это скорее большое исключение, встречающееся в хорошо «оттюненных» СХД, встречающихся в реальном мире, к сожалению, лишь немногим чаще упомянутого круглого копытного. Подробное объяснение я хотел было привести в статье, но она у меня и так распухла до невозможности. Наверное можно про это отдельный пост сделать. Хотите?
на подобной нагрузке, даже в плохо «оттюненных» СХД будет читаться full stripe, что обычно значительно больше чем 256КБ
и чтение будет упреждающим, если конечно туда еще не добрались руки «тюнеров» 😉
Олег, хорошее замечание. Гибридные системы сами себя «тюнят», им «тюнеры» не нужны почти. Вообще же, это целая наука, как сделать так, чтобы система писала Full stripe хотя бы просто «почаще», а читаемые данные брала преимущественно из буфера упреждающего чтения. И уже почти этого не делают с введением автоматизированного хранения, когда блоки данных «ездят» по системе сами(!), а тома разных приложений замешаны винегретом на общих гибридных дисковых пулах с разными уровнями raid. Так что рассматриваемая ситуация, когда пишутся полные страйпы и читаются длинные префетчи — это скорее счастливое исключение. Но бывает, наверное.
Уведомление: Подводные камни резервного копирования новых СХД. Ч. 3. Дедупликации и катастрофы | Блог Дениса Серова