RAID

Для отправки уведомлений, у нас будет использоваться

почтовый ящик alarm@adminunix.ru,

сервер исходящей почтыadminunix.ru

паролем: super_password

email администратора у нас будет it@adminunix.ru
В вашем случае, данные для подключения к почтовому серверу и адрес получателя, необходимо указать свои.

Настройка отправки почты с сервера:
Для начала установим пакет ssmtp:

sudo apt-get install ssmtp

Настраиваем ssmtp

Отредактируем конфигурационный файл:

sudo mcedit /etc/ssmtp/ssmtp.conf

Приведя его в к виду указанному ниже:

 # Config file for sSMTP sendmail
 #
 # The person who gets all mail for userids < 1000
 # Make this empty to disable rewriting.
 root=postmaster

#Указываем логин пользователя, для подключения к почтовому серверу
 authuser=alarm
 #Указываем пароль для подключения
 authpass=super_password
 AuthMethod=LOGIN
 # The place where the mail goes. The actual machine name is required no
 # MX records are consulted. Commonly mailhosts are named mail.domain.com
 #Адрес сервера исходящей почты
 mailhub=adminunix.ru
 rewriteDomain=adminunix.ru #принудительное указание домена в поле From
 # Where will the mail seem to come from?
 #rewriteDomain=
 # The full hostname Очень желательно, чтобы hostname совпадал с PTR записью IP адреса, с которого будем устанавливать соединение, но не обязательно. hostname=ts174-23.adminunix.ru
 # Are users allowed to set their own From: address?
 # YES - Allow the user to specify their own From: address
 # NO - Use the system generated From: address
 FromLineOverride=NO #Запрещает скриптам «решать» с какого ящика отправлять письмо.

теперь отредактируем алиасы для отправки почты:

mcedit /etc/ssmtp/revaliases

Добавим в него следующее:

root:alarm@adminunix.ru:adminunix.ru
 postmaster:alarm@adminunix.ru:adminunix.ru

#for yandex
 root:alarm@yandex.ru:smtp.yandex.ru:465
 ubuntu:alarm@yandex.ru:smtp.yandex.ru:465
 postmaster:alarm@yandex.ru:smtp.yandex.ru:465

#for gmail
 root:alarm@gmail.com:smtp.gmail.com:587
 ubuntu:alarm@gmail.com:smtp.gmail.com:587
 postmaster:alarm@gmail.com:smtp.gmail.com:587

Если необходимо отправлять почту через smtp.yandex.ru

mailhub=smtp.yandex.ru:465 #адрес и порт smtp сервера яндекса
 UseTLS=YES #Использование шифрования SSL/TLS

Если необходимо отправлять почту через smtp.gmail.com

 mailhub=smtp.gmail.com:587
 UseSTARTTLS=YES

для FreeBSD изменим почтового клиента используемого по умолчанию:

mcedit /etc/mail/mailer.conf

приведем его к следующему виду:

#sendmail/usr/libexec/sendmail/sendmail
 #send-mail/usr/libexec/sendmail/sendmail
 #mailq<>/usr/libexec/sendmail/sendmail
 #newaliases/usr/libexec/sendmail/sendmail
 #hoststat/usr/libexec/sendmail/sendmail
 #purgestat/usr/libexec/sendmail/sendmail
 sendmail/usr/local/sbin/ssmtp
 send-mail/usr/local/sbin/ssmtp
 mailq/usr/local/sbin/ssmtp
 newaliases/usr/local/sbin/ssmtp
 hoststat/usr/bin/true
 purgestat/usr/bin/true

Для проверки работы SSMTP

echo test | mail -v -s "testing ssmtp setup" it@adminunix.ru

Если вы хотите настроить отправку писем для своего веб-сайта на php, измените файл php.ini:

#for apache
 sudo nano /etc/php5/apache2/php.ini
 #for nginx and php-fpm
 sudo nano /etc/php5/fpm/php.ini[/bash]

Найдите строку sendmail_path (она задокументирована с помощью 😉 и ниже неё вставьте:

sendmail_path = ssmtp -t

Отправка писем из скриптов bash/shell

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

#!/bin/bash
 du -sh | mail -s "disk usage report" it@adminunix.ru

Откройте новый файл, вставьте в него приведенные выше строки, сохраните и запустите. Вы получите письмо, содержащее вывод команды «du -sh».
И последняя хитрость в письмах из командной сроки — добавление вложений к письмам, отправляемым из скриптов. Предположим, вам необходимо сделать резервную копию директории с конфигурационными файлами, заархивировать ее и отправить в качестве вложения с помощью mutt:

#!/bin/bash
 tar -zcf /home/user/backup.tar.gz /home/user/files_to_backup
 echo "Archived configuration files" | mutt -a /home/user/backup.tar.gz -s "backup data" it@adminunix.ru

Команда echo в начале третьей строки добавляет текст «Archived configuration files» в тело письма.

#!/bin/bash
 df -h > /tmp/mail_report.log
 free -m >> /tmp/mail_report.log
 mail -s “disk and RAM report” it@adminunix.ru < /tmp/mail_report.log

настройка Mdadm

Отредактируем настройки mdadm

sudo nano /etc/mdadm/mdadm.conf

Находим строку MAILADDR и вписываем туда адрес получателя уведомлений:

MAILADDR it@adminunix.ru

перезапускаем Mdadm

sudo /etc/init.d/mdadm restart

Теперь нам необходимо протестировать отправку уведомлений от Mdadm, в командной строке пишем:

mdadm --monitor --scan -1 --mail=it@adminunix.ru --test

Проверяем почтовый ящик админа, там будет лежать письма о состоянии RAID массива, такого содержания:

This is an automatically generated mail message from mdadm
running on Server_name.tld

A TestMessage event had been detected on md device /dev/md/0.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities: [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
 md0: active raid1 sdb1[2] sda1[0]
 19529656 blocks super 1.2 [2/2] [UU]

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

This is an automatically generated mail message from mdadm
running on Server_name.tld

A FailSpare event had been detected on md device /dev/md/0.

It could be related to component device /dev/sdb1.

Faithfully yours, etc.

P.S. The /proc/mdstat file currently contains the following:

Personalities: [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
 md0: active raid1 sdb1[2](F) sda1[0]
 19529656 blocks super 1.2 [2/1] [U_]

Значит все отлично, система работает, уведомления отправляются и в случае чего, вы будете готовы все поднимать, а в нашей индустрии, быстро поднятое не считается упавшим…

1. RAID выйдет из строя со 100% вероятностью

This post is allegedly about surprising facts. But this fact should not surprise you. Still, some folks invest in RAID with the expectation that it removes the burden of backing up their files. Don’t make that mistake.

Instead, you should think about RAID as the first tier in your data protection strategy. When you consider which RAID configuration you might use, think about the coming day when the entire volume will be corrupted. I’m not talking about just one disk. I mean the whole shebang.

What’s your data recovery plan? How frequently are you willing to put up with the hassle to restore your data?  Some RAID implementations are aimed at making failure an infrequent event. Other configurations significantly increase the chance of failure.

Make sure you have a backup plan, then consider your RAID options in that context.

Fact 1 may not have been so surprising. Here are a few more that might actually surprise you:

2. Software RAID is almost always a better choice than hardware RAID

Software RAID has advanced significantly in the last few years (as of 2012). Hardware RAID still has the three key vulnerabilities it has always had: First, it is expensive. Second, if your RAID card fails, your RAID volume fails; it is a single point of failure. Third, if your RAID card fails, you must find an exact replacement for that card to recover your data.

On the other hand, software RAID costs nothing, and if your controller card or motherboard fail, you can just move your disks to another machine and set up the appropriate software to read them.

Yes, hardware RAID can be faster than software RAID, but that gap is closing, and the flexibility and reliabilty offered by software RAID outweighs that single advantage. The only case where hardware RAID is the right choice is when absolute speed is the only priority, and you’re willing to take risks with your data.

There are some articles on the web that compare hardware versus software RAID.  They are good reading, but in some cases the information they contain is old. You should be sure to make your decisions on the state of the art. As of 2012 there are a number of new capabilities offered by software RAID that make it worth considering:

• Hot swapping works with software RAID. SATA 3G and SATA 6G made that possible. If a disk goes bad, swap it out, no down time.
• Software RAID only consumes a small slice of CPU cycles. In my tests with mdadm on ubuntu I saw only 2% to 4% of one CPU dedicated to RAID. On a multi-core machine this is nothing.
• Software RAID works with SSD caching. The most used data migrates to a very fast cache.
• Software RAID supports variable size volumes that can be extended by adding more disks (specifically ZFS supports this, maybe others do as well).

3. Some “RAID cards” aren’t hardware RAID

Over the last few years SATA disk controller cards and motherboards have come out that claim to offer hardware RAID. They are really just disk controllers with BIOS that implements RAID in software.

How can you detect these cards and motherboards? Usually price is the giveaway. A $20.00 card is not likely to implement true hardware RAID. Also these cards usually offer windows-only support. Here’s a good.

4. On-disk data compression can make your RAID volume faster

That seems counter-intuitive because it takes computing power and time to compress data. Here’s why it can make your disk performance faster: The bottleneck in disk IO is bandwidth to the disk (your SATA pipe). If the data is compressed before writing, there’s less of it to write, so it moves more quickly to the disk.

ZFS offers compressed volumes.  I’m sure other software RAID implementations offer it as well. Here’s some discussion of this.

5. Maybe you don’t need RAID at all

Consider an SSD instead. Yes, SSDs are expensive, but a single SSD is less expensive than the multiple disks you’d need to build a comparably fast RAID volume. For example, as of this writing (May 2012) an Intel 250GB SSD prices in at $350 and it’s faster than many RAID configurations built with spinning disks. See one of my other posts for [urlspan]details[/urlspan] on SSD speeds compared with RAID on SATA 3G.

SSDs can also be used as cache for a RAID volume. For our next server I’m contemplating a two disk mirror for reliability, augmented with an SSD cache for speed. This can be done easily with ZFS.

And yes, for ultra crazy speed, you can build a RAID volume out of SSDs.

7. If speed is the only priority, choose RAID0

In RAID0 the data is split or “striped” across the multiple disks and written (or read) in parallel.  With N disks, speed up is N-times for reading and N-times for writing.  Here’s the downside though: Total failure of your RAID volume is N-times more likely. You should assume that RAID volume failure is an absolute certainty.

Choose RAID0 only if you can easily rebuild your RAID volume. Make sure you have a strong backup workflow.

8. If reliability is the only priority, choose RAID1

RAID1 is called “mirroring.” The data is fully duplicated on two (or more) disks. If one disk fails everything is OK; The RAID volume will continue operating, and it can be rebuilt when you replace the defective disk. RAID0 also offers N-times speed up for reads, but no speed up for writes.

9. In nearly all other cases, RAID10 is the way to go

In RAID10, pairs of disks are mirrored to create reliable volumes (RAID1), then those reliable volumes are combined via RAID0 for speed. Four disks combined in this way offer 2 times speedup over a single disk for reads and writes, yet they can also sustain loss of two disks and still operate. You get both speed and reliability.

Many folks would consider RAID5 for these applications. I think its a bad choice nowadays in comparison to RAID10 because RAID5 is subject to very slow write speeds; sometimes slower than writing to a single disk. See my tests here. Also RAID5 can only survive loss of one disk. In a 4 disk setup RAID10 can sustain two disk losses.

The main advantage of RAID5 is that it offers more total storage than RAID10. But the speed and reliability of RAID10 more than offset that advantage.

What about the other RAID levels? The three I mention above cover 99% of RAID use cases. The situations in which other RAID levels are useful are limited. If you want to dive in though, here’s a good [urlspan]starting point[/urlspan].

10. And the tenth surprising fact about RAID: There are only 9 surprising facts about RAID!

Столкнулся с медленной синхронизацией программного RAID.

Я использую Ubuntu Server и software raid mdadm, который объединяет 3ТБ диски в RAID1. После создания массива mdadm делает resync, который в моем случае предлагал завершить через 40000 минут. Я решил ускорить синхронизацию дискового массива. 

Для ускорения перестроения RAID нужно записать в /proc/sys/dev/raid/speed_limit_min определяет максимальную скорость записи, которую mdadm будет использовать для реконструкции дискового массива.

Снимаем ограничение:

echo 300000 > /proc/sys/dev/raid/speed_limit_min

Смотрим, что получилось:

watch --interval=1 cat /proc/mdstat

Скорость выросла до 147 МБ/с — это практически максимальная скорость записи, которую можно получить на используемых дисках.

md3 : active raid1 sdb5[1] sda5[0]
 2779548480 blocks super 1.2 [2/2] [UU]
 [===>.................] resync = 15.9% (443292288/2779548480) finish=264.1min speed=147420K/sec

Если один из дисков в программном RAID выходит из строя, то по умолчанию Ubuntu при загрузке не запустит ОС, а останется в консоли initramfs.

Это может помочь сохранить данные, предупредив полную неработоспособность RAID массива. Но это также может стать проблемой, если сервер используется в удаленном режиме — доступ к нему будет потерян.

Загружаться или нет с неполностью рабочим RAID система определяет по параметру BOOT_DEGRADED в файле /etc/initramfs-tools/conf.d/mdadm.

Чтобы система запустилась, нужно установить «BOOT_DEGRADED=true».

Также это может быть переопределено указанием для ядра опции bootdegraded=[true|false] при загрузке.