Выделенные сервера: системы хранения данных

Любой современный проект сталкивается с важной задачей хранения информации. Таким хранилищем сегодня могут быть различные системы: File storage, Block storage, Object storage, Key-value storage.

Выделенные сервера и системы хранения данных

В любом нормальном проекте перед приобретением определенного storage-решения проводятся специальные тесты для проверки конкретных параметров в конкретных условиях. Вспомнив, сколько превосходных, сделанных опытными руками проектов прокололись именно на том, что просто забыли про масштабируемость, мы захотели разобраться:

• Какие характеристики File storage и Block storage необходимо учитывать, если желаете, чтобы при росте вашего проекта система хранения росла вслед за ним.
• Почему отказоустойчивость на уровне ПО дешевле и надежнее, нежели на hardware уровне.
• Как правильно выполнять тестирование.
• Как получить на порядок меньше/больше IOPS, поменяв лишь один параметр.

В процессе тестирования мы использовали RAID–системы, а также распределенную систему хранения информации Parallels Cloud Storage или PStorage. PStorage входит в известный продукт под названием Parallels Cloud Server.

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

• Отказоустойчивость.
• Скорость восстановления информации.
• Производительность, которая соответствует вашим запросам.

Отказоустойчивость

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

Для обеспечения отказоустойчивости при сбое существует единственная техника, а именно резервирование. Вопрос в том, на каком уровне используется резервирование. Говоря проще, можно сказать, что уровня лишь два: Software и Hardware.

Резервирование на hardware уровне давно себя зарекомендовало в Enterprise-системах. NAS/SAN коробки имеют специальное двойное резервирование модулей (два, три блока питания, несколько плат «мозгов») и сохраняют информацию сразу на нескольких дисках внутри коробки. Можно себе представить это, как очень надежную кружку: очень надежную для сохранения внутри жидкости, с толстыми стенками и в обязательном порядке с двумя одинаковыми ручками на тот случай, если одна из них вдруг сломается.

Резервирование на уровне software еще только начинает понемногу проникать в различные Enterprise-системы, однако с каждым годом отъедает все более крупный кусок у HW решений. Принцип здесь предельно прост.

Эти системы на надежность железа не полагаются. Они считают, что оно ненадежно априори, и решают все задачи резервирования на уровне программного обеспечения, создавая копии информации и храня их на физически различном железе. Продолжая нашу аналогию с кружками, это — когда есть несколько абсолютно обычных чашек, и вы разлили чай в обе, на тот случай если одна вдруг разобьется.

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

Теперь следует рассказать, как решить вопрос резервирования на примере PStorage. Последний не имеет специальной привязки к какому-то вендору железа и может работать на абсолютно обычных машинах, вплоть до обычных ПК. Мы не доверяем современному железу, в связи с чем архитектура PStorage целиком рассчитана на потерю любого физического сервера полностью (а не только лишь отдельного диска).

Вся информация в Parallels Cloud Storage надежно хранятся в нескольких копиях. PStorage при этом никогда не хранит больше одной копии на физическом сервере/комнате. Мы советуем хранить три копии данных для того, чтобы быть хорошо защищенным от одновременного сбоя двух серверов/комнат.

Скорость восстановления информации

Что происходит, когда один из дисков ломается?

Вначале рассмотрим простой HW RAID1 (mirror) из двух дисков. При поломке одного диска, RAID все-таки продолжает работать с оставшимся, при этом ожидая замены сломавшегося диска. То есть, в это время RAID уязвим. Оставшийся же диск хранит одну единственную копию информации.

Сколько именно времени вся система находится в очень уязвимом состоянии — полностью зависит от времени восстановления. Такую зависимость описывает формула:

MTTDL ~= 1 / T^2 * С, где T – время восстановления,
(MTTDL) — это среднее время наработки до потери информации, С — коэффициент.

Итак, чем система быстрее восстановит необходимое число копий информации, тем вероятность потерять данные меньше. Здесь мы опустим то, что для начала восстановления HW RAID администратору необходимо заменить сломанный диск на новый, а на это также надо время, в особенности если диск необходимо заказывать.

Для RAID1 время восстановления – время, за которое контроллер RAID перельет информацию с рабочего диска на новый. Как можно легко догадаться, общая скорость копирования равна будет скорости чтения и записи HDD. То есть приблизительно 100 Мб/сек, если RAID контроллер абсолютно не нагружен. Если в это время контроллер RAID грузят извне, скорость будет в разы ниже.

Вдумчивый пользователь проведет аналогичные расчеты для RAID5, RAID10, RAID6 и придет к выводу, что любой современный HW RAID восстанавливается с общей скоростью не больше скорости одного диска.

NAS/SAN системы практически всегда применяют аналогичный простому RAID подход. Они группируют все диски, собирают из них RAID. Скорость восстановления та же.

На software уровне намного больше возможностей для полноценной оптимизации. К примеру, в PStorage информация распределяется по всему кластеру, а также по всем дискам кластера. В случае поломки одного из дисков репликация включается автоматически. Здесь не надо ждать, когда администратор поменяет диск.

Вдобавок, в репликации принимают участие все диски кластера, в связи с чем скорость восстановления информации гораздо выше.

Как тестировать производительность — рекомендации

Основываясь на нашем большом опыте тестирования систем хранения информации, я бы выделил ключевые правила:

• Необходимо определиться с хотелками, что именно получить хочется от системы, ну и сколько. Большинство применяет Parallels Cloud Storage для организации кластера высокой доступности для контейнеров и виртуальных машин. Каждая из машин кластера предоставляет одновременно и storage, и выполняет виртуальные машины. Так, в кластере не требуется внешней выделенной «хранилки данных». Таким образом, кластер нагрузку получает от каждого сервера.
• Не нужно использовать хорошо сжимаемые шаблоны информации. Многие HDDs и SSDs диски, виртуальные машины и системы хранения данных иногда имеют особые Low-level оптимизации для полноценной обработки нулевых-данных. В подобных ситуациях можно легко заметить то, что запись нулей на диск осуществляется немного быстрее, нежели запись случайных данных. Примером подобной ошибки служит известный тест:
  dd if=/dev/zero of=/dev/sda size=1M
• Лучше применять при тестировании случайные данные. При этом генерация такой информации не должна влиять на тест. То есть лучше сгенерировать случайную информацию заранее, к примеру в файл. В другом случае тест обязательно упрется в генерацию информации, как в этом примере:
  dd if=/dev/random of=/dev/sda size=1M
• Учитывайте общее расстояние между компонентами, которые разнесены друг от друга. Разумеется, коммуникация между распределенными элементами содержать может задержки. Следует помнить об этом узком месте при нагрузках. В особенности сетевых задержках, пропускной способности выбранной сети.
• Отведите не менее минуты на выполнение теста. Время теста обязательно должно быть продолжительным.
• Выполняйте один тест пару раз для того, чтобы сгладить все отклонения.
• Используйте крупный объем информации для нагрузки (Working set). Working set – это крайне важный параметр, поскольку он очень влияет на общую производительность. Именно он способен изменить результат тестирования в много раз.
• Всегда сравнивайте лишь «яблоки с яблоками». Нужно сравнивать системы с аналогичной отказоустойчивостью на таком же железе. К примеру, нельзя сравнивать PStorage с RAID0, так как PStorage обеспечивает полную отказоустойчивость при вылете серверов/дисков, а RAID0 нет. В этом случае будет правильно сравнивать PStorage с RAID1/6/10.

Выводы

Резюмирую:

• Выбирая разновидность резервирования, если у вас выделенные сервера склоняйтесь именно к «уровню ПО». Уровень Software предоставляет намного больше возможностей для оптимизации, а также позволяет существенно снизить требования к железу, несколько удешевить хостинг в целом.
• Тесты проводить следует на особых условиях.
• Обращаете ваше внимание на скорость восстановления. Это крайне важный параметр, который при низкой эффективности может просто погубить часть бизнеса.

Отзывы о хостинге: