Показаны сообщения с ярлыком RAID. Показать все сообщения
Показаны сообщения с ярлыком RAID. Показать все сообщения

четверг, 17 марта 2011 г.

Автоматическая дефрагментация баз Exchange 2007 - практика

Редко, но метко бывает нужно провести дефрагментацию большого количества больших баз Exchange 2007, для этих целей решил написать скрипт для Exchange Management Shell, поскольку ночью спать сильно хочется, а днем, даже в выходные дни, куча пользователей (из более чем 1200) может сидеть в базах и мешать их дефрагментировать своими недовольными звонками начальству и в тех поддержку ))).
Вообщем, использую скрипт:


####################################
#Shiryaev.DE@gmail.com
#скрипт выполняет автоматическую дефрагментацию баз для всех групп хранения CCR кластера Exchange 2007
########################
$Array_DBs = Get-MailboxDatabase | select-object name, servername, storagegroup, EdbFilePath | Sort-Object -Property name

"Count of Databases=" + ([string] $Array_DBs.Length)

for($i=0;$i -le $Array_DBs.Length-1;$i++)
{
$DB_FULL_NAME = ([string] $Array_DBs[$i].server)+"\"+([string] $Array_DBs[$i].Name)
$DB_NAME = $Array_DBs[$i].name
$DB_FILE_NAME = $Array_DBs[$i].EdbFilePath
$SG_NAME = $Array_DBs[$i].storagegroup

If ( ([string] $Array_DBs[$i].servername) -eq "MailCluster-01")
{
"["+$i+"]---Suspend-StorageGroupCopy <<" + $SG_NAME + ">>"
Suspend-StorageGroupCopy -Identity $SG_NAME -SuspendComment "Suspending CCR to reseed." -Confirm:$false
Start-sleep -s 6

"---Dismount-Database <<" + $DB_NAME + ">>"
Dismount-Database $DB_NAME -Confirm:$false
Start-sleep -s 6
"---ESEUTIL.EXE /D <<" + $DB_NAME + ">>"
ESEUTIL.EXE /d $DB_FILE_NAME /tf:\tempdb.edb
Start-sleep -s 6
"---Mount-Database <<" + $DB_NAME + ">>"
Mount-Database $DB_NAME -Confirm:$false
Start-sleep -s 6
"---Resume-StorageGroupCopy <<" + $SG_NAME + ">>"
Resume-StorageGroupCopy -Identity $SG_NAME
}
else
{
"[" + ($i+1) + "]" + "Storage Group name" + $SG_NAME + " is NOT Clustered nothing to do with DB <<" + $DB_NAME + ">>."
}
}

Немного статистики:
на сервере HP DL580G5 с 32Gb RAM и размещением всех баз на RAID5, состоящем из 4х FC15k дисков дефрагментация 11-ти баз, которая ни разу не проводилась для 80% объема от 323Gb, составляет 30000seconds, или 500minutes, или 8 hours 20 minutes, что весьма приемлемо провести за одну ночь - запустив дефрагментацию перед уходом домой вечером, например, в пятницу.
моя статистика по базам их размещению, объему, времени прохождения бэкапа и коэффициент от объема ко времени в минутах.

F:\Ex2k7_00__SG_Unlim --- 45G --- 2294s --- k = 1,17
F:\Ex2k7_01stSG_Public_Folders --- 3,6G
F:\Ex2k7_02ndSG_500Limit --- 2G --- 253s --- k = 0,71
F:\Ex2k7_03thSG_300Limit --- 45G --- 2047s --- k = 1,31
F:\Ex2k7_04thDisabled_SG --- 10G --- 461s --- k = 1,30
F:\Ex2k7_05thSG_300Limit --- 40G --- 4022s --- k = 0,59
F:\Ex2k7_11thSG_1000Limit --- 1G --- 487s --- k = 0,12
G:\Ex2k7_06thSG_300Limit --- 88G --- 11070s --- k = 0,47
G:\Ex2k7_07thSG_300Limit --- 48G --- 3334s --- k = 0,86
G:\Ex2k7_08thSG_300Limit --- 49G --- 3898s --- k = 0,75
G:\Ex2k7_09thSG_300Limit --- 16G --- 1070s --- k = 0,89
G:\Ex2k7_10thSG_300Limit --- 16G --- 1064s --- k = 0,90

Фактически k - это коэффициент скорости дефрагментации. Как видно сам скрипт не оптимален, поскольку расположение временного файла статично, а не вычисляется исходя из расположения файла базы данных, так если временный файл на том же диске F, то коэффициент выше, для баз, расположенных на диске G коэффициент падает.

То что соотношение размеров баз не оптимизировано - это всё в будущем ;-)

пятница, 19 ноября 2010 г.

Как собрать RAID на Citrix Xen Server

Конфигурирование программного RAID массива на 4х дисках, каждый емкостью 1Т.
Поключаемся к Xen через SSH/Telnet из под root.
Проверяем наличие дисковых устройств в системе командой:
ls –l /dev



Проверяем информацию о дисковых разделах:
Fdisk -l



Проверяем наличие RAID устройств зарегистрированных в системе:
ls /dev



Подготавливаем диски к созданию RAID, для этого используем последовательность команд для каждого из 4х дисков /dev/sdd/, /dev/sdb, /dev/sdc, /dev/sde:



Последовательно копируем структуру таблицы разделов с 1-го подготовленного диска на 3 остальных командой:
sfdisk –d /dev/ | sfdisk /dev/[destination disk]







Проверяем подготовленные для RAID разделы на указанных дисках:



Создаем устройство для RAID командой:
mknod /dev/md1 b 9 1
Проверка создания командой:
ls /dev



Объединяем подготовленные диски в RAID, которые автоматически распределяться далее.



Смотрим нагрузку на подсистемы во время распределения RAID – фактически максимальная нагрузка на 4 диска:



Завершение:



Создаем логический том для Xen при помощи LVM для хранения виртуальных машин на распределяемом RAID массиве:



Проверяем созданный раздел через Citric XenCenter:



Копируем конфигурацию RAID массива в файл /etc/mdadm.conf



Смотрим содержимое файла:



Смотрим конфигурацию LVM:




Использование RAID контроллеров в Linux

вторник, 2 ноября 2010 г.

после переноса виртуальной машины на ESX остается .vmss файл

Переносили плагином svmotion на ESX виртуальные машины между дисками без выключения, при этом решил убедиться, что все файлы машин перенеслись полностью, поскольку диск располагался на системе хранения через SAN и планировалось удалить поданный LUN с целью переделки RAID-а. Оказалось, что у одной из машин не перенесся файл .vmss

Поскольку машина была в работе - на всякий случай выключил её.

Файлы вида .vmss нужны для того что бы машина находилась в состоянии "Приостановлено" ("Suspend"), и только для этого, если машина включена или выключена, то этот файл можно смело удалять. Если же машина находиться в приостановленном состоянии и вы удалите этот файл, то после запуска машина просто начнет загрузку ОС с начала и всё.

На всякий случай проверил отсутствие snapshot-ов у машины, после чего удалил файл .vmss и запустил виртуальную машину. Машина запустилась без ошибок.

вторник, 10 августа 2010 г.

О ClARiiON и зеркальном RAID на разных дисковых полках

Хоть NaviSphere и предупреждает, что так делать не желательно, - всё равно собрал RAID 1 на разных дисковых полках - одно плечо на 0-й полке, другое - на 1-й полке, всего 6 дисков - по три на полку, причем такой RAID не собирается через графический интерфейс NaviSphere-ы, а только через NaviCli

командой вида(ручное указание пар дисков в 10 RAID на CLARiiON CX4-120):

Пример1:

naviseccli -h clariion-main-spa createrg 10 0_0_5 0_1_5 0_0_6 0_1_6 0_0_7 0_1_7 -pri high -rm no -raidtype r1_0

или:

Пример2:

naviseccli -h clariion-main-spa createrg 10 0_0_5 0_0_9 0_0_6 0_0_10 0_0_7 0_0_11 0_0_8 0_0_12 -pri high -rm no -raidtype r1_0

Итак, после того как выключали дисковый массив, и включили его заново, как и предупреждает NaviSphere, что не создавайте RAID 1 на разных полках поскольку 0-я полка инициализируется быстрее и выполучите degrade на время ресинхронизации (rebuilding):