Подводные камни резервного копирования новых СХД. Ч. 1. Гибридные системы

2012.10.01-cloud-backup-comic

Взгляд на эволюцию резервного копирования.  Взято вот тут http://www.nten.org

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

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

Статья переехала в Блог EMC на Хабре.

Подводные камни резервного копирования новых СХД. Ч. 1. Гибридные системы: 10 комментариев

    • Fargon, время копирования =объем в МБ делить на скорость в МБ/сек. Для каждого уровня считаем время его бэкапа и складываем все вместе. Для нижнего уровня скорость бэкапа самая низкая — 40 мб/сек. 5мб/сек на один диск NLSAS.

      • Денис, а откуда берется цифра 5 мб/сек на один шпиндель NL-SAS? Эмпирически выведена? Тут еще я так понимаю должна быть зависимость и того, какой именно NL-SAS диск используется — 1, 2, 3, 4 или 6 Тб?

        За статью спасибо. В самом деле заставляет задуматься.

      • Хороший вопрос. Я полез в VNX best practices, а там сейчас пишут характерную скорость 15 мб/сек с NLSAS диска. Правда оговариваются, что это скорость при «одновременном многопоточном чтении большими блоками». Я бы такую скорость для бэкапа не закладывал. Что касается 5МБ/сек с диска, то я ее рассчитал в нулевом приближении взяв быстродействие диска 80 IOPS и помножив на размер блока 64 КБ. Это типичная гранулярность при построении RAID. Эта цифра довольно хорошо соответствует наблюдению в реальных ситуациях, когда диски специально для тестов не «тюнят», и не нагружают синтетикой.

  1. Денис, спасибо, полезно, я как раз делал эту ошибку — закладывал большие и медленные диски в нижний тир, не думаю о времени восстановления. Жду новых статей.

  2. «взяв быстродействие диска 80 IOPS и помножив на размер блока 64 КБ»

    это крайне странный размер блока для фулл бэкапа ;-), т.к. для данной нагрузки более типично потоковое чтение с размером блока от 256КБ
    то есть для сферического коня в вакууме, все же будет порядка 80х256КБ=20MBps
    в реальной жизни с одной рейд-группы на таких NL HDD вполне можно снимать порядка 150MBps
    при чем, если мы говорим о прогретой СХД с 3-уровневым хранением, то на NL не будет сколь-нибудь заметного I/O, способного замедлить бэкап (т.к. это самый «холодный» уровень)
    то есть все действительно печально, но не настолько драматично, как предполагает автор 😉

    • Олег, спасибо за комментарий. Тема не спроста про «подводные камни». Чтение 256КБ с файловой системы или БД далеко не всегда приводит к чтению 256КБ с физического диска. Это скорее большое исключение, встречающееся в хорошо «оттюненных» СХД, встречающихся в реальном мире, к сожалению, лишь немногим чаще упомянутого круглого копытного. Подробное объяснение я хотел было привести в статье, но она у меня и так распухла до невозможности. Наверное можно про это отдельный пост сделать. Хотите?

      • на подобной нагрузке, даже в плохо «оттюненных» СХД будет читаться full stripe, что обычно значительно больше чем 256КБ
        и чтение будет упреждающим, если конечно туда еще не добрались руки «тюнеров» 😉

      • Олег, хорошее замечание. Гибридные системы сами себя «тюнят», им «тюнеры» не нужны почти. Вообще же, это целая наука, как сделать так, чтобы система писала Full stripe хотя бы просто «почаще», а читаемые данные брала преимущественно из буфера упреждающего чтения. И уже почти этого не делают с введением автоматизированного хранения, когда блоки данных «ездят» по системе сами(!), а тома разных приложений замешаны винегретом на общих гибридных дисковых пулах с разными уровнями raid. Так что рассматриваемая ситуация, когда пишутся полные страйпы и читаются длинные префетчи — это скорее счастливое исключение. Но бывает, наверное.

  3. Уведомление: Подводные камни резервного копирования новых СХД. Ч. 3. Дедупликации и катастрофы | Блог Дениса Серова

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s