четверг, 23 апреля 2009 г.

EMC AVAMAR - система резервного копирования с глобальной дедупликацией на стороне клиента



Ниже приведены заметки о системе распределенного резервного копирования с дедупликацией данных на стороне клиентов EMC Avamar.

Avamar поставляется в 3 видах - как ПО, как устройство (сервер и ПО) и как виртуальная машина.

Устройства (appliance) поставляются в виде сервера, дистрибутива ОС (оптимизированный RedHat) и комплекта дистрибутива Avamar, которые интегратор должен самостоятельно поставить на этот сервер.

Устройство (appliance) 1 ТБ укомплектовано 6 дисками SAS, находящимися в RAID 5.
Устройство (appliance) 2 ТБ укомплектовано 6 дисками SATA, находящимися в RAID 10.
Доукомплектовать устройства дисками невозможно, если закуплено устройство в 1 ТБ и понадобится расширить емкость, придется закупать новое устройство. При этом объединить в RAIN архитектуру устройства разного объема невозможно.
В архитектуре RAIN есть роли storage node и utility node. Utility node не хранит информации, в нем 2 диска в RAID 1.

ПО можно ставить только на довольно узкий список поддерживаемых серверов. Для Avamar 4.X cейчас поддерживаются:
Dell PowerEdge 2950III, HP DL320s, HP DL360 G5 c MSA 60, HP DL365 с MSA60, HP DL380 G5, HP DL385 G2, IBM x3650.
Процессоры поддерживаются только 64-bit.

AVE - Avamar Virtual Engine версия 1,2 Требует 64-битного процессора.
AVD - виртуальная машина для демонстрации, позволяет сохранить около 10 ГБ - дедуплицированных данных. Запускается на VMWare workstation, требует 1 ГБ оперативной памяти. Работает на 32-битных процессорах.

Виртуальная машина с Avamar может быть 0,5 - 1 - 2 ТБ. Требует соответственно 3 - 4 - 16 ГБ RAM.
Процессор строго 64-бит .

Avamar проверяет сохраненные данные в фоновом режиме после окончания плановых резервных сессий резервного копирования. При этом некоторые служебные процессы (garbage collection) не должны пересекаться с сессиями резервного копирования во времени.

Дедупликация происходит на клиенте. Алгоритм работы ПО на клиенте следующий.

1. При помощи алгоритма Sticky-byte Factoring (вычисление бегущего хэша в 32 бита) выделяются сегменты из сохраняемых данных. Размер сегментов - от одного байта до 64 КБ.
2. Сжатие сегментов
3. Вычисление хэша SHA-1 (20 байт) для каждого сжатого сегмента и файлов целиком.
4. Commonality Factoring - запрос сервера Avamar на наличие в нем уникального сегмента.
5. Передача уникальных сегментов и метаданных на сервер Avamar.


На клиенте содержатся 2 файла с кэшем хэшей -
f_cahe.dat - содержит хэши файлов и метаданные
p_cache.dat - хэши фрагментов, отправленных на сервер

Рекомендуют устанавливать размер файлов f_cahe.dat в 1/8 от объема RAM а p_cache.dat 1/16 от объема RAM. При резервном копировании эти файлы выгружаются в RAM.

Root hash - хэш файла, его уникальный идентификатор.

Скорость работы клиентского приложения - сканирование примерно 1 млн объектов в час. Скорость резервного копирования - около 100 ГБ/час. Восстановление проходит дольше - около 25 ГБ в час (до 40 ГБ в час). Сильно зависит от типа данных.

После первичной дедупликации отсекается около 30 % данных. Для оценки первичной дедупликации есть вспомогательное ПО - avasst.exe Это набор скриптов, которые запускают клиента avamar и подсчитывают процент уникальных сегментов.

Если данные забьют хранилище сервера, он перейдет в режим Read Only. После этого требуется вручную запускать процесс очистки (garbage collection).

При резервном копировании данных файловой системы 15 рабочих станций, (копировали все кроме программ и windows) дедупликация получилась 1:20 (на 300 ГБ хранились 5,7 ТБ полезных данных).

На 1 узел максимально возможно 18 одновременных сессий их которых 17 сессий используется для клиентов и 1 для репликации.

Общего места на дисковой подсистеме требуется в 1,5 раза больше, чем доступно для хранения дедуплицированных данных резервного копирования. Это связано с проверкой данных в фоновом режиме и хранении двух check point.

Данные Avamar хранятся в специализированной базе данных GSAN. Ее элементы называются stipe, их максимальный размер - 360 МБ. После прохождения процесса Garbage Collection ненужные блоки помечаются, но не удаляются. Для высвобождения места должен пройти процесс crunch - формирования новых страйпов или сжатие старого страйпа без копирования.

65 % дискового пространства на сервере Avamar отводятся для хранения данных, выше этого объема система переходит в режим read-only. (например, при лицензировании на 1 ТБ, 1 ТБ -
Это 65 % от общей емкости дисковой подсистемы).

Рекомендуется применять Avamar при активности изменения файлов не более 5% за день. Avamar неоптимально работает с аудио, видео, архивами, мультиплексированными данными.

Рекомендуют подвергать резервному копированию не более 2 ТБ на одном клиенте. Максимальный объем дедуплицированных данных, хранимых в RAIN Avamar - 32 ТБ.

Конкурент Avamar - Pure Disk. У него лицензии дешевле, но взимаются за объем до дедупликации. У Avamar лицензии считаются после дедупликации.

пятница, 17 апреля 2009 г.

Symmetrix V-Max - новое поколение Hi-End массивов от компании EMC


14 апреля 2009 г. корпорация EMC анонсировала новое поколение систем храненияданных высшего класса Symmetrix V-Max.

Система позиционируется как инфраструктурная основа виртуальных центров обработки данных.

Основная новинка - Virtual Matrix Architecture. Новая архитектура позволяет масштабировать систему значительно больше, чем предыдущая архитектура Direct Matrix.

М-Max представляет собой многоузловую распределенную систему хранения данных, способную масштабироваться от одного до восьми высокодоступных управляющих блоков V-Max. В каждом дисковом блоке может быть размещено до 240 дисков.

СХД поддерживает набор дисков - Flash (диски второго поколения по 200 и 400 ГБ), Fibre Channel, and SATA. Позволяет более удобно организовать уровневую группировку данных на дисковых подсистемах разной производительности и стоимости. Количество дисков, размещаемое в системе - от 96 до 2400. Полезный объем дисковой подсистемы - до 2 ПБ. В системе может быть размещено до 944 ГБ зеркалированной памяти, до 128 портов Fibre Channel, 64 портов FICON, 64 портов Gigabit Ethernet или iSCSI.

Разработана новая версия операционной среды Enginuity - 5874.

Более подробно тут и тут.

Запрос пароля при удалении Symantec Antivirus

Памятка для преодоления запроса пароля при удалении антивируса Symantec.

В реестре на клиентской машине следует изменить параметр

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\LANDesk\VirusProtect6\CurrentVersion\AdministratorOnly\Security параметр UseVPUninstallPassword=1

"1" надо заменить на "0" и перезагрузиться. После этого пароль при удалении ПО запрашиваться не будет.

понедельник, 13 апреля 2009 г.

Некорректное распознавание размера раздела в ОС виртуальной машины после его расширения на гипервизоре VMWare ESXi 3.5

Иногда при расширении разделов дисков виртуальных машин при помощи инструментов сторонних разработчиков (например, GParted или Acronis) в операционных системах Windows XP/2003 происходит ситуация, когда в оснастке управления дисками размер диска показан корректно, а размер раздела - старый. И ОС видит диск только старого размера, без приращения свободного места.

Это вызвано сбоем в работе утилиты изменения таблицы разделов после расширения диска (видимо, при работе утилиты ntfsresize). Подобна ситуация возникает, как правило, если виртуальная машина быва выключена аварийно или на диске имелись ошибки.

Одно из решений -
  1. проверить диск утилитой chkdsk ,
  2. перезагрузить ОС штатным образом,
  3. загрузиться в утилиту расширения дисков, например gparted,
  4. уменьшить размер диска на небольшую величину с применением изменения,
  5. увеличить размер диска до требуемой величины с применить изменения.
Если после 5 шага программа не выдаст ошибки, то все ОК и диск расширен корректно. После этого при первом включении виртуальной машины запустится проверка диска во время начального этапа загрузки ОС, после произойдет перезагрузка и ОС загрузится в нормальном режиме.

Источник - http://www.seandeasy.com/expanding-a-drive-within-a-vmware-image/

четверг, 9 апреля 2009 г.

Модуль повышения производительности устройств NetApp (PAM)

На недавнем мероприятии компании Network Appliance (NetApp Innovation 2009) рассказывали о модуле повышения производительности для систем хранения данных этого изготовителя.


Модуль Performance Acceleration Module (PAM) оптимизирует работу приложений, осуществляющих много операций случайного чтения, например файловых служб. Модуль представляет собой интеллектуальный кэш чтения. Один модуль, представляющий собой плату PCI Express с модулями памяти DDR2, увеличивает кэш чтения до 16 ГБ. В старшие модели можно установить 5 модулей с общим объемом кэша чтения 80 ГБ. Модули поддерживаются ОС NetApp Data ONTAP 7.3.

Устройство представляет собой кэш второго уровня, куда перемещаются блоки данных, вытесненные из буферного кэша WAFL ( NetApp® Write Anywhere File Layout). Наилучший эффект от использования этого устрйоства достугается при наличие большого количества операций случайного чтения данных небольшого объема (почтовые сообщения, файловый обмен, домашние папки). Алгоритм ПО, работающего с модулем, определяет тип данных (случайного или последовательного доступа) и размещает их в кэш. Модуль может работать в 3 режимах -
  • Default mode - кэшируются данные и метаданные,
  • Metadata mode - кэшируются метаданные,
  • Low-priority mode - кэшируется также данные с последовательным чтением и другиенизкоприритетные данные.



Для оценки эффективности применения PAM для Data ONTAP 7.3 есть модуль Predictive Cache Statistics software, который позволяет эмулировать работу этого модуля и показать эффективность его применения.

На сайте изготовителя заявляется, что "Согласно недавно опубликованным результатам эталонного тестирования NetApp, по пропускной способности ввода-вывода система FAS3140 с модулями NetApp PAM и дисками SATA эквивалентна той же системе, но только с вдвое большим числом дисков Fibre Channel со скоростью вращения 1500 об/мин."

Правда, стоимость этого модуля получается существенной (сравнима с одной дисковой полкой) и его применение экономически оправдано в средних и больших системах.

пятница, 3 апреля 2009 г.

Создание и удаление сервисов в Windows XP

Сервисы Windows XP могут быть добавлены или удалены из командной строки. Для этого надо знать внутреннее имя сервиса, а не его "Display Name". Например, "Help and Support" - это отображаемое имя, а "helpsvc"- это имя внутренне. Внутреннее имя сервиса можно узнать в описании сервиса из оснастки "Сервисы" (services.msc).

Создание сервиса из командной строки


Удаление сервиса из командной строки

Удаление сервиса из реестра

В редакторе реестра (regedit.exe) окрыть ветку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services,
найти внутреннее имя интересующего сервиса и удалить его. После этого перезагзурить систему.

Источник - http://www.theeldergeek.com/add_a_service_in_windows_xp.htm

четверг, 2 апреля 2009 г.

Перенос файлов базы данных в MS SQL 2005

Памятка по переносу файлов базы данных MS SQL 2005 на другой диск. Например, когда закончилось место на текущем диске.
  1. Остановить приложения, обращавшиеся к базам.
  2. Запустить интерпретатор команд SQL, мы использовали SQL Server Management Studio.
  3. Проверить отсутствие подключений к переносимым базам командой sp_who
  4. Проверить имена переносимых баз командой sp_helpdb
  5. Отключить переносимую базу командой sp_detach_db имя_переносимой_базы
  6. Физически перенести файлы базы данных (имя_переносимой_базы.mdf и имя_переносимой_базы_log.ldf) на новый диск. Операция выполняется в любом файловом менеджере/командной строке.
  7. Подключить базу командой sp_attach_db @dbname='имя_переносимой_базы',@filename1='D:\новый_путь\имя_переносимой_базы.mdf', @filename2='D:\новый_путь\имя_переносимой_базы_log.LDF'
  8. Проверить доступность базы.

среда, 1 апреля 2009 г.

Проблема с расширением диска виртуальной машины на гипервизоре ESXi 3.5

Столкнулся с довольно неприятной, но просто решаемой проблемой. Диск на виртуальной машине отказывался расширяться. То есть ESXi в панели "Resent Tasks" как положено писал об удачном завершении операции - Status "Complited". Но при последующем открытии свойств виртуальной машины у расширяемого диска оказывался старый, неувеличенный размер. Подобная ситуация обнаружилась у ряда других машин.

Причина этой проблемы оказалась простой - у проблемных виртуальных машин были сделаны снимки дисков, snapshot. После удаления снимков расширение диска проходит в штатном режиме.

Помог форум VMWare -
http://communities.vmware.com/message/1065588#1065588