AE Devs

Наверное все знают, что SSD это круто в плане скорости чтения. Но совсем не круто в плане скорости записи, и еще менее круто в плане живучести. Особенно MLC устройства.

Для того, чтобы решить обе эти проблемы в среде Windows, к каждому SSD девайсу прилагается тулз который позволяет настроить over-provisioning.  Но что делать *nix-администраторам?

Для того чтобы все было айс и тру – нам нужна тулза hdparm, и SSD винт должен быть подключен не в рейд-контроллер, а напрямую к SATA порту.

1. Устанавливаем мастер-пароль для SSD.
   hdparm –user-master u –security-set-pass 123 /dev/sdb
2. Выполняем secure erase.
   hdparm –user-master u –security-erase 123  /dev/sdb
3. Ограничиваем доступный размер диска. Нужное вам количество секторов посчитайте сами.
   hdparm -Np1234567890 /dev/sdb

Если по какой-то причине с пунктом 3 у вас не сложилось, например как у нас – проблема с HPA, которую лениво решать, то можно его заменить: при создании рейда (если планируете использовать SSD  в рейде) либо при создании разделов (если планируете использовать SSD как самостоятельное устройство) вы должны указать только часть реального объема диска. Например – 80%. Или 50%. Все оставшееся после подобной разметки пустое место SSD автоматически применит для wear-off leveling, что значительно продлит жизнь вашему SSD и однозначно придаст ему бодрости при записи.

Пост пишу с планшета, потому не будет пространных объяснений, только резюм и факты

• Для AoE Target используем только GGAoED.
• Для AoE Initiator используем только свежие модули, и компиляем руками. Пакетные из ядра – в /dev/null
• На таргете direct-io=true
• На инициаторе io scheduler ставим noop.
• На обоих сетевухах и свитче между ними включаем опцию Jumbo Frames. Размер фрейма 8192.
• Hardware flow control.
• noatime, nodiratime – без вариантов.
• XFS и Ext3/4 желательно использовать с barrier=1
• Буфера на сетевых картах поднимать сверх всякой меры.
• Процессу GGAoED приоритет ionice – максимальный. Вплоть до realtime.

Положим, вам не повезло, и у вас побился файл таблицы mysql.users, а бэкапа нет. И repair не помогает. И войти на сервер уже нельзя. И пользователи негодуют. Как быть?

Расскажу, как мы решили подобную проблему однажды.

1. Выключаем покалеченный сервер.
2. Подкладываем содержимое var/mysql с любого “здорового” сервера аналогичной версии
3. Запускаем сервер, и входим с логином/паролем “здорового” сервера.

Начиная с этого момента, у нас уже есть рут-доступ к серверу бд. Теперь нужно восстанавливать пользователей.

Если ваши условия схожи с нашими, то файлы  у вас разложены в в определенном порядке и с определенной структурой.  В нашем случае логины мы знаем зная путь к папке пользователя.
Т.е. фактически из тройки сервер-логин-пароль, два элемента мы уже знаем. Остается узнать установленные ранее пароли. И сделаем мы это просто:

find /directory -type f -exec grep ‘{sql.server.ru}’ \; >mysql.log

На выходе, в файле mysql.log мы получим список файлов, в котором встречается указанный вами адрес сервера.

После этого остается только распарсить файлы на предмет паролей, и затулить их обратно в базу данных.
Что опять же, не очень сложно, если формат пароля более-менее стандартизирован, и основные CMS известны: Joomla, WordPress, Drupal, e107, SMF, phpBB итд. Детали парсинга, если пожелает, раскроет fer0x.

Несколько часов жужжания – и 95% паролей восстановлено. Оставшиеся 5% – восстанавливать прийдется руками, по мере обнаружения не восстановленных.

когда он судорожно вспоминает дату  создания последнего бэкапа

Сегодня я расскажу о прошедших выходных, и мертвом винте на рейде.

MegaCli64 -LDInfo -LALL -a0

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-6, Secondary-0, RAID Level Qualifier-3
Size                : 8.177 TB
State               : Partially Degraded
Strip Size          : 64 KB
Number Of Drives    : 20
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Cached, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Cached, No Write Cache if Bad BBU
Access Policy       : Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
Default Power Savings Policy: Controller Defined
Current Power Savings Policy: None
Can spin up in 1 minute: Yes
LD has drives that support T10 power conditions: No
LD's IO profile supports MAX power savings with cached writes: Yes

Значиццо в рейде есть мертвый диск.

Ищем и находим:

MegaCli64 -PDList -a0

Вывалит инфу по всем дискам. Ищем наш:

Enclosure Device ID: 31
Slot Number: 12
Enclosure position: 0
Device Id: 20
Sequence Number: 4
Media Error Count: 2
Other Error Count: 4
Predictive Failure Count: 0
Last Predictive Failure Event Seq Number: 0
PD Type: SATA
Raw Size: 465.761 GB [0x3a386030 Sectors]
Non Coerced Size: 465.261 GB [0x3a286030 Sectors]
Coerced Size: 465.25 GB [0x3a280000 Sectors]
Firmware state: Unconfigured(bad)
SAS Address(0): 0x5003048000d01f58
Connected Port Number: 0(path0)
Inquiry Data: WD-WMAYP1206128WDC WD5003ABYX-01WERA0 01.01S01
FDE Capable: Not Capable
FDE Enable: Disable
Secured: Unsecured
Locked: Unlocked
Needs EKM Attention: No
Foreign State: None
Device Speed: 3.0Gb/s
Link Speed: 3.0Gb/s
Media Type: Hard Disk Device
Drive: Not Certified
Drive Temperature :31C (87.80 F)

Смотрим в лог контроллера, что там произошло:

/17/11 22:46:23: EVT#06910-09/17/11 22:46:23: 267=Command timeout on PD 14(e0x1f/s12) Path 5003048000d01f58, CDB: 28 00 01 bf 1e 80 00 00 80 00^M
09/17/11 22:46:23: EVT#06911-09/17/11 22:46:23: 267=Command timeout on PD 14(e0x1f/s12) Path 5003048000d01f58, CDB: 28 00 27 a0 23 80 00 00 80 00^M
09/17/11 22:46:23: EVT#06912-09/17/11 22:46:23: 267=Command timeout on PD 14(e0x1f/s12) Path 5003048000d01f58, CDB: 28 00 0d 5d 1d 17 00 00 08 00^M
...........
...........
...........
09/17/11 22:50:13: Disc-prog= 0....resetProg=0 aenCount=0 transit=0 ^M
09/17/11 22:50:14: EVT#06995-09/17/11 22:50:14: 113=Unexpected sense: PD 14(e0x1f/s12) Path 5003048000d01f58, CDB: 28 00 0b 77 f3 3f 00 00 08 00, Sense: 6/29/00^M
09/17/11 22:50:14: Raw Sense for PD 14: 70 00 06 00 00 00 00 0a 00 00 00 00 29 00 00 00 00 00^M
09/17/11 22:50:14: HDD read error from RDM!!!!!^M
09/17/11 22:50:14: HDD Read FAILURE!!!! Id 71 line 0^M
09/17/11 22:50:14: FAILED: Id 71 block 57fca2d7 num 16^M

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

Смотрим в смарт, чего там с пострадавшим винтом:

smartctl -a -d megaraid,20 /dev/sda

Интересует нас раздел значений и порогов.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate     0x002f   198   198   051    Pre-fail  Always       -       66784
3 Spin_Up_Time            0x0027   164   143   021    Pre-fail  Always       -       2758
4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       41
5 Reallocated_Sector_Ct   0x0033   134   134   140    Pre-fail  Always   FAILING_NOW 1363
7 Seek_Error_Rate         0x002e   200   163   000    Old_age   Always       -       0
9 Power_On_Hours          0x0032   097   097   000    Old_age   Always       -       2238
10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       38
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       37
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       3
194 Temperature_Celsius     0x0022   113   110   000    Old_age   Always       -       30
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       1363
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   200   200   000    Old_age   Always       -       0
200 Multi_Zone_Error_Rate   0x0008   001   001   000    Old_age   Offline      -       79357

Вот:   5 Reallocated_Sector_Ct   0×0033   134   134   140    Pre-fail  Always   FAILING_NOW 1363

Эта ошибка – это уже признак неизбежной смерти винчестера.  1363 бэд сектора были переназначены. Это число теперь будет только расти, т.к. диск “начал сыпаться”. И мы его уже не можем использовать, для нас это уже мусор.

Итого, осталось достать старый винт из сервера, и вставить новый.

А что касается рейда – с ним всё отлично, как только умер один жесткий диск, первый из hot-spare дисков был подключен, и рейд автоматически начал восстанавливаться на нем. Сутки ожидания, и – порядок!

Единственное, отмечу, что на время восстановления рейда среднее время Iowait выросло на 15 миллисекунд.

Итак,  дано следующее:

• raid-контроллер LSI, скажем LSI 9260-8i или любой другой контроллер LSI.
• raid6 на 20 дисков
• 12 новых HDD
• среднесуточная нагрузка – 1300 IOPS на чтение, 135 IOPS на запись.

Делаем следующе:

1. Удостоверяемся, что у нас есть свежий бэкап всего находящегося на рейде, и располагается этот бэкап не на этом рейде.
2. Убеждаемся, что рейд который мы хотим растянуть находится в оптимальном состоянии:
   MegaCli -LDInfo -LALL -a0 

   В выдаче ищем вот это:
   State               : Optimal

3. Вставляем в сервер новые HDD.
4. Получаем список дисков сервера:
   MegaCli64 -PDList -a0
   смотрим на диски в статусе Unconfigured Good, и записываем их Enclosure Device ID и Slot Number.
5. Запускаем расширение рейда:
   MegaCli -LDRecon -Start -r6 -Add -Physdrv[EnclosureID1:SlotNumber1,EnclosureID2:SlotNumber2,EnclosureID3:SlotNumber3] -LRAID -aController
   с реальными параметрами это будет выглядеть примерно так:
   MegaCli -LDRecon -Start -r6 -Add -Physdrv[21:17,21:18,21:19] -L0 -a0
   
6. C момента запуска, категорически не рекомендуется что-либо делать с сервером примерно 1 неделю. При наличии нагрузки на рейде, именно столько займет растягивание рейда и его последующая инициализация.

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

• Рейд будет принудительно переведен в режим Direct-IO, кэширования чтения со стороны контроллера не будет.
• Рейд будет принудительно переведен в режим Write-Through, кэширования записи со стороны контроллера не будет.
• Средний IOwait поднимется на 5-50 миллисекунд, в зависимости от приоритета реконструкции и инициализиации.

Также следует обратить внимание на еще пару системных нюансов:

• Если вы хотите изменить приоритет реконструкции или инициализации, сделать это вы должны ДО начала процесса растягивания рейда.
• В существующих драйверах и прошивках LSI 92хх есть баг: по завершении процесса добавления новых дисков вы никак не заставите систему увидеть новое пространство. Для этого понадобится перезагрузка операционной системы.