Выбор стораджа как выбор автомобиля
Я уже пользовался этой аналогией в одном моем полусерьезном посте ранее, из за своей "всеобщности" сравнение с автомобилем понятно и наглядно. Поэтому воспользуемся этой аналогией еще раз.
Я уже пользовался этой аналогией в одном моем полусерьезном посте ранее, из за своей "всеобщности" сравнение с автомобилем понятно и наглядно. Поэтому воспользуемся этой аналогией еще раз.
Тема магнитных лент не отпускает долго. Тем не менее, приближаемся к финалу.
В прошлой и позапрошлой статье под заголовком “Так ли незаменимы магнитные ленты для бэкапов” я рассмотрел два популярных “кейса”, считающихся классической “вотчиной” ленточного метода хранения, а именно: удаленное хранение копии и “длиные” retention, или циклы хранения копий, и показал, как эти задачи могут быть решены с использованием дисковых систем хранения, в частности интересующих меня NetApp.
Обычно “в пику” дискам сторонники лент приводят два возражения. Во-первых – как сделать удаленное хранение, о варианте решения этой задачи я говорил в прошлом посте. Во-вторых — как организовать “длинные” циклы retention. Несмотря на то, что я рассказывал в самом первом посте цикла, о той разнице, которая разделяет понятие “резервная копия” и “архивная копия”, многие компании хотят иметь резервные копии на протяжении значительного периода времени, например года, такие резервные копии уже постепенно переходят по своему статусу в “архивные”, но согласен, что длинный цикл ротации бэкапов, с возможностью откатиться на довольно отдаленный момент времени состояния данных может быть удобен во многих случаях.
Итак, в двух предыдущих постах серии я попытался вас убедить, что на сегодняшний день устройства для записи на магнитную ленту (стримеры или ленточные библиотеки, “tape library”) часто значительно проигрывают в удобстве, цене и надежности решения простым и эффективным дисковым NAS-массивам на дисках SATA.
В прошлый раз мы начали разговор о том, насколько полезно забивать шурупы молотком правильно рассматривать магнитные ленты как единственную опцию в качестве способа хранения данных при резервном копировании, и пришли к выводу, что примененяя их для задачи резервного копирования мы сталкиваемся с рядом существенных, и что самое неприятное, врожденных и неизлечимых их недостатков.
Недостатков этих лишены дисковые системы хранения, которые, впрочем, долгое время, пока не случилось обвальное удешевление недорогих дисков SATA, использовать для хранения резервных копий было накладно. Однако при сегодяшних ценах дисковые массивы уже вполне способны составить конкуренцию магнитным лентам по цене хранения, одновременно будучи лишены уже названных выше недостатков.
Разберем их чуть детальнее:
Есть такая поговорка про “зашоренность мышления” и следование типовыми путями:
“Если в руке молоток, то все вокруг кажется гвоздями”
в том смысле, что когда человек смотрит на задачу только с одной стороны, то всегда хочется выбрать уже известное решение, даже если возможное решение и не одно.
Одним из самых консервативных направлений в IT является направление систем и устройств резервного копирования.
Действительно, зачем “искать от добра добра”, всю жизнь использовали ленты (зачастую это не метафора, подозреваю что у большинства меня читающих вся жизнь, с рождения и по сегодня, с запасом уложилась в срок существования магнитных лент как средства хранения информации в индустрии), зачем от них отказываться, раз и так все работает?
“Эффективность” это, в общем случае, соотношение между “вложенным” и “полученным”.
В случае если мы говорим об “эффективности хранения”, то это соотношение между количеством купленных байт (raw) и тем объемом, который в результате можно записать вашими данными (usable).
Аспект эффективности к сожалению все еще несколько недооценивается, когда перед клиентом стоит задача выбора системы хранения.
Когда я, еще в 2007 году писал небольшой обзор программы IOmeter, которой как раз незадолго до этого измерял показатели производительности некоторых моделей систем хранения NetApp, я не предполагал, что эта небольшая заметка станет с той поры «бестселлером». Неожиданно для себя я обнаружил, что подробного описания работы с таким популярным средством тестирования и измерения на русском языке просто нет. Не так давно коллега track написал гораздо более подробное описание настройки и работы с IOmeter, и c его любезного согласия, я публикую этот текст.
Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (random) по характеру доступ.
Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.
Одной из вечных тем FUD-а конкурентов NetApp является «проблема» с фрагментаций данных в WAFL.
Оставим сейчас в стороне вопрос, насколько фрагментация действительно проявляется в практической жизни (я на эту тему уже писал ранее). Рассмотрим только вопрос того, насколько такой эффект вообще имеет место быть в теории.