Куда уходит место на дисках?
Одна из проблемных областей администраторов платформ виртуализации — куда девается место на дисках?
А все просто. (далее...)
Одна из проблемных областей администраторов платформ виртуализации — куда девается место на дисках?
А все просто. (далее...)
Я уже пользовался этой аналогией в одном моем полусерьезном посте ранее, из за своей "всеобщности" сравнение с автомобилем понятно и наглядно. Поэтому воспользуемся этой аналогией еще раз.
Тема магнитных лент не отпускает долго. Тем не менее, приближаемся к финалу.
В прошлой и позапрошлой статье под заголовком “Так ли незаменимы магнитные ленты для бэкапов” я рассмотрел два популярных “кейса”, считающихся классической “вотчиной” ленточного метода хранения, а именно: удаленное хранение копии и “длиные” retention, или циклы хранения копий, и показал, как эти задачи могут быть решены с использованием дисковых систем хранения, в частности интересующих меня NetApp.
Есть такая поговорка про “зашоренность мышления” и следование типовыми путями:
“Если в руке молоток, то все вокруг кажется гвоздями”
в том смысле, что когда человек смотрит на задачу только с одной стороны, то всегда хочется выбрать уже известное решение, даже если возможное решение и не одно.
Одним из самых консервативных направлений в IT является направление систем и устройств резервного копирования.
Действительно, зачем “искать от добра добра”, всю жизнь использовали ленты (зачастую это не метафора, подозреваю что у большинства меня читающих вся жизнь, с рождения и по сегодня, с запасом уложилась в срок существования магнитных лент как средства хранения информации в индустрии), зачем от них отказываться, раз и так все работает?
Для полноценной работы почти всего функционала ESX, кроме непосредственного запуска виртуальных машин, требуется shared storage, разделяемое хранилище. Для HA и VMotion, и того, что с ними связано — DRS, Fault Tolerance.
Но что делать если нет денег на HP EVA, NetApp и даже на Starwind iSCSI? Спасут старые добрые пингвины и старенький, уже слабый, но все еще исправно работающий сервер.
Итак, берем сервер, очень желательно с аппаратным RAID и обязательно с гигабитной сетью, и набиваем его дисками. Программная часть: CentOS, iSCSI Enterprise Target и/или стандартный NFS сервер, идущий в комплекте с CentOS. Я взял дистрибутив, бывший под рукой, CentOS 5.3 32bit.
(далее...)
“Эффективность” это, в общем случае, соотношение между “вложенным” и “полученным”.
В случае если мы говорим об “эффективности хранения”, то это соотношение между количеством купленных байт (raw) и тем объемом, который в результате можно записать вашими данными (usable).
Аспект эффективности к сожалению все еще несколько недооценивается, когда перед клиентом стоит задача выбора системы хранения.
Когда я, еще в 2007 году писал небольшой обзор программы IOmeter, которой как раз незадолго до этого измерял показатели производительности некоторых моделей систем хранения NetApp, я не предполагал, что эта небольшая заметка станет с той поры «бестселлером». Неожиданно для себя я обнаружил, что подробного описания работы с таким популярным средством тестирования и измерения на русском языке просто нет. Не так давно коллега track написал гораздо более подробное описание настройки и работы с IOmeter, и c его любезного согласия, я публикую этот текст.
Несколько слов о теме влияния фрагментации данных на скорость доступа к ним, которую я начал в прошлый понедельник заметкой о теоретической модели, показывающей сравнительно малое влияние фрагментации на случайный (random) по характеру доступ.
Однако как обстоят дела с последовательным (sequental) доступом, ведь такой тоже имеет место быть (пример – записи в лог базы данных)? Очевидно, что тут-то и должна проявиться в полный рост проблема фрагментации, и ее влияния на производительность.
Одной из вечных тем FUD-а конкурентов NetApp является «проблема» с фрагментаций данных в WAFL.
Оставим сейчас в стороне вопрос, насколько фрагментация действительно проявляется в практической жизни (я на эту тему уже писал ранее). Рассмотрим только вопрос того, насколько такой эффект вообще имеет место быть в теории.
Сокращенный перевод поста Chris Lionetti, Reference Architect – Microsoft Solutions Engineering
Этот пост рассматривает проблему Unrecoverable Error Rate (UER), «Уровня невосстановимых ошибок» на жестких дисках.