Игорь Олемской — практические заметки по системному администрированию Linux CentOS

Для желающих протестировать ipset 4.5 под CentOS/RHEL 5.x собрал RPM пакеты под i386/x86_64 архитектуры. Скачать можно здесь http://centos.alt.ru/pub/temp/ipset-4.5/. Штатный iptables в CentOS не содержит модуля set, пришлось его немного пропатчить. ipset -V ipset v4.5, protocol version 4.Kernel module protocol version 4. Если проблем не выявится, то данные пакеты уйдут в репозиторий CentALT.

Порт ipfw для Linux существует давно. Я даже собрал RPM пакеты для CentOS 5 Рассказываю как быстро порезать входящий/исходящий трафик на машине с NAT. Пример 1 Режем полосы вх/исх в 1Mbit/s для каждого из ip адресов подсети 10.0.0.0/24 #!/bin/bash ipfw -f flush ipfw pipe 1 config bw 1000Kbit/s mask dst-ip 0x000000ff ipfw pipe 2 config [...]

В данный статье речь пойдёт о замечательной утилите sc — предназначенной для упрощения управлением правилами шейпера в Linux. На данный момент программа обладает следующими возможностями: Шейпинг с помощью классификатора u32 с использованием хэширующих фильтров Полисинг с помощью классификатора u32 с использованием хэширующих фильтров Шейпинг с помощью классификатора flow + управление списками доступа с помошью ipset [...]

Попытаюсь в этой статье рассказать об особенностях применения хранилища InnoDB в высоконагруженных проектах, а так же дать поверхностное сравнение MyISAM и InnoDB. Безусловно, MySQL не ограничивается только этими двумя типами хранилища данных, однако они являются подавляющими в своей распространенности использования.

Несмотря на то, что много в InnoDB для меня очевидно, все еще остаются некоторые темные пятна и если меня где то поправят, буду только благодарен.

Почему народ выбирает InnoDB? InnoDB обладает преимуществами перед MyISAM.

1. Транзакционная модель. Это конечно преимущество не столько для администратора, сколько для программиста. Программист может объединить операции с базой в транзакцию, с кучей вытекающих из этого профита. Это основная причина по которой архитекторы выбирают InnoDB.
2. Блокировка на уровне строки. В отличии от MyISAM, где идет блокировка на уровне таблицы, в InnoDB блокировка осуществляется на уровне строки. Проблема конкурентных блокировок стоит не так остро как в MyISAM, однако все таки присутствует. Но об этом ниже.
3. Защита от сбоев. InnoDB более устойчивая к сбоям, если сказать точнее, InnoDB намного лучше восстанавливается после сбоев и практически не теряет данные. Для восстановления же MyISAM таблиц зачастую требуется потушить MySQL сервер и вручную восстанавливать таблицы утилитой myisamchk. Результатом работы myisamchk зачастую может оказаться частичная или полная потеря данных в таблице. InnoDB восстанавливается автоматически.
4. Качественная работа с IO. InnoDB имеет свой собственный Buffer Pool в памяти, где держит таблицы. Для InnoDB можно отключить системную буферизацию IO при работе с таблицами InnoDB. Таким образом, можно сказать что в InnoDB нет двойной буферизации (как в MyISAM), следовательно, оперативная память разумно расходуется.

MyISAM конечно же тоже обладает преимуществами, в основном это простота и скорость. На небольших объемах данных и большом количестве операций чтения лучше хранилища не найти, если конечно вам не нужны транзакции. Но сейчас не об этом. На этой ноте про MyISAM больше ни слова.

InnoDB не готова корректно работать из коробки на высоких нагрузках. Надо хорошо понимать о происходящих в недрах InnoDB процессах дабы правильно настроить этот тип хранилища.

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

innodb_file_per_table

По умолчанию, InnoDB использует общее хранилище для всех таблиц и индексов. Данная опция позволяет содавать на каждую таблицу свой .ibd файл. Наиболее частая причина применения этой опции – раскидать отдельные таблицы по отдельным физическим устройствам.

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

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

Использование выделенных блочных устройств под хранилище

Киллер-фича InnoDB. Вы можете использовать целые партиции или физические устройства вместо файлов общего хранилища InnoDB. Это сразу убирает всякую системную буферизацию ввода-вывода и всякий оверхед файловой системы. В этом случае InnoDB пишет данные прямо на устройство. Конечно же, это создает ряд ньюансов в процедуре резервного копирования.

Для того чтобы использовать эту возможность, пропишите в конфигурации

[mysqld]
innodb_data_home_dir=
innodb_data_file_path=/dev/hdd1:3Gnewraw;/dev/hdd2:2Gnewraw

После старта InnoDB сделает инициализацию блочных устройств. Очень важно после этого остановить сервер и в конфигурации поменять «newraw» на «raw»:

[mysqld]
innodb_data_home_dir=
innodb_data_file_path=/dev/hdd1:3Graw;/dev/hdd2:2Graw

и перезапустить сервер. Иначе при следующем перезапуске, если InnoDB встретит «newraw», партиция будет заново отформатирована!

Так же надо иметь в виду, что пользователь, под которым запускается MySQL должен иметь права на запись в обозначенные партиции.

При использовании данной возможности, очевидно лучше для InnoDB выделять логические тома LVM. Это существенно упрощает бекап (по снятому снапшоту) и восстановление.

innodb_buffer_pool_size

Размер памяти, выделяемый под кеш данных и индексов. Строго говоря, чем больше таблиц сидит в этой памяти, тем лучше. Если есть возможность, размер этого буфера должен быть чуть больше общего размера innodb таблиц. Однако он не должен быть больше 80% объема ОЗУ.

innodb_log_file_size

Размер файла лога транзакций. Чем больше размер, тем реже InnoDB будет сбрасывать страницы Buffer Pool на диск, и тем больше требуется времени на восстановление после аварии. Размер варьируется от нескольких мегабайт до размера innodb_buffer_pool_size, но не более 4Gb суммарно во всех лог-файлах.

innodb_log_buffer_size

Размер буфера памяти для записи лога транзакций. Размер варьируется в пределах единиц-десятков мегабайт. Большой размер буфера позволяет запускать объемные транзакции без сброса лога на диск, что позволяет уменьшить IO при объемных транзакциях.

innodb_flush_log_at_trx_commit

Принимает одно из трех значений: 0, 1, 2. При значении 1, лог скидывается на диск при каждом коммите транзакции и буфер записи так же скидывается на диск. При 0 эта операция производится не при каждой транзакции а 1 раз в секунду. При значении 2, лог скидывается на диск при каждом коммите, но сброс буферов не производится.

Если вы ищете производительность в ущерб надежности – ставьте 0. Если наоборот – ставьте 1.

innodb_thread_concurrency

Количество рабочих тредов InnoDB. Начать надо с количества ядер CPU*2 + количество физических блочных устройств. Мне всегда этой формулы хватало. Официальная документация рекомендует поиграть с этим значением.

innodb_flush_method

Установка характера работы с файловой системой. Данная переменная не имеет эффекта при использовании выделенных блочных устройств под хранилище. Представляет из себя комбинацию значений O_DSYNC,O_DIRECT,fdatasync. Если вы используете большой размер innodb_buffer_pool_size, имеет смысл дать InnoDB доступ к файлам, минуя системные буфера с помощью опции O_DIRECT.

В официальном руководстве сказано, что при использовании определенных Storage Area Network, O_DIRECT может дать серъезный пенальти производительности.

Для OS GNU/Linux читайте про опции O_DSYNC (O_SYNC) и O_DIRECT на данной странице руководства open (2). FreeBSD очевидно имеет много сходств с GNU/Linux в этом вопросе.

Для OS MS Windows © ® ™ данная опция не имеет смысла, как и данная статья вообще.

innodb_locks_unsafe_for_binlog

Эта опция не может быть никак пропущена, если у вас серьезная нагрузка на конкурентную запись. Очень сложно это объяснить, да и не понимаю я этого до самой глубины, но если вкратце…

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

Например, если вы используете чтение по диапазону (SELECT a FROM b WHERE c>100) внутри тразакции, то с включенной опцией innodb_locks_unsafe_for_binlog, следующий такой же запрос вернет тот же результат, даже если между ними кто то что то в эту таблицу пытался писать.

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

То есть, эта опция во включенном состоянии снимает туеву хучу локов при конкурентной записи-чтении в таблицы. Цена вопроса – не обеспечивается консистентный снапшот данных на время всей транзакции. Как то так в общем.

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

Ах да. И для репликации соответственно это не канает.

innodb_lock_wait_timeout

Довольно странная настройка, но она имеет место и является частой причиной потери данных. Когда тред ожидает снятия блокировки строки для модификации записей, он ожидает вплоть до указанного в этой опции количества секунд. По умолчанию это 50 секунд. Если за 50 секунд блокировка не была снята, транзакция отваливается с ошибкой

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

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

Программистов нужно предупреждать (если они не в курсе), что если они словили ошибку 1205 от InnoDB, то надо повторить или отложить транзакцию! Поскольку эта ошибка де-факто не может быть воспроизведена в тестовых условиях, очень часто программисты не в курсе и бывают весьма удивлены, наблюдая пробелы в потоках данных.

Собрал RPM пакет ipt_statistic модуля iptables для выполнения заданных действий с пакетом с определенной вероятностью. Установка yum install ipt_statistic Пример использования iptables -A INPUT -p icmp -m statistic --mode random --probability 0.5 -j DROP Подробней iptables -m statistic --help Скачать RPMS и SRPMS для CentOS 5 можно здесь. Либо подключив репозиторий CentALT.

Pacemaker – набор утилит от ClusterLabs для управления распределением ресурсов вычислительного кластера.

Pacemaker позволяет гибко распределять ресурсы по узлам кластера, следить за их доступностью, поднимать в случае падения ресурса, отрабатывать failover целого узла.

Если говорить кратко, Pacemaker работает по принципу Heartbeat, только расширяет его функциональность до высоких высот. Во-первых, Pacemaker может управлять более чем двумя узлами кластера, во-вторых, мониторить состояние ресурсов, в-третьих, позволяет ресурсы клонировать. И еще много-много чего другого.

Pacemaker представляет из себя конгломерат из пакетов Pacemaker, Corosyc, OpenAIS, Heartbeat. Pacemaker использует транспорт сообщений Corosync/OpenAIS либо Heartbeat для взаимодействия между узлами кластера. При этом действующий транспорт в кластере может быть только одного типа: либо Corosync/OpenAIS, либо Heartbeat.

Не смотря на то, что предпочтительным транспортом является Corosync, пакет Heartbeat так же должен быть установлен, поскольку он включает в себя достаточно большое количество OCF скриптов для управления ресурсами кластера.

За работу Pacemaker в CentOS отвечают два LSB-скрипта:

/etc/init.d/corosync
/etc/init.d/openais

За конфигурацию Pacemaker на отдельной ноде отвечают файлы:

/etc/corosync/corosync.conf - конфигурация corosync
/etc/corosync/authkey - авторизационный ключ для работы в кластере
/etc/corosync/service.d/pcmk - файл для связки corosync и pacemaker

Конфигурация кластера представляет из себя единый внутренний файл, изменения в который можно вносить на любой ноде с помощью утилиты crm. Изменения распространяются по другим нодам в качестве diff’ов автоматически.
За конфигурацию кластера отвечает единая консольная утилита crm.
Мониторинг состояния кластера: crm status – мгновенный слепок состояния, crm_mon – реалтайм мониторинг из консоли.

Основные понятия

Узлы (ноды,nodes) кластера

Узел (нода,node) кластера представляет из себя машину с установленным Pacemaker и включенным в состав кластера.

Управление нодами кластера осуществляется через команду crm node:

crm node standby node1 - переключить node1 в режим простоя
crm node online node1 -  переключить node1 в рабочий режим
crm node fence node1 - убить (выключить) при помощи STONITH node1
crm node help - справка по операциям с узлами

Узлы, предназначенные для выполнения одинаковых ресурсов должны иметь одинаковую конфигурацию софта, который используется ресурсами. То есть, если ресурс res1 ocf:heartbeat:apache предполагается запускать на узлах node1,node2,node3 и он использует определенный нестандартный модуль mod_rpaf, то все три узла должны иметь установленный apache и mod_rpaf одинаковых версий. Это исключает ситуацию, когда ресурс при перемещении между узлами может запуститься на одном ушле и не может на другом.

Ресурсы

Что есть ресурс с точки зрения pacemaker? Все, что может быть заскриптовано. Обычно скрипты пишутся на bash, но ничто не мешает вам писать их на Perl, Python или даже на C. Все, что требуется от скрипта, это выполнять 3 действия: start, stop и monitor. В общем-то скрипты должны соответствовать LSB (Linux Standard Base) или OCF (Open Cluster Framework) — последнее несколько расширяет LSB, требуя также передачи параметров через переменные окружения с особым названием.

Ресурс может представлять из себя:

• IP адрес
• Демон с определенной конфигурацией
• Блочное устройство
• Файловую систему
• etc

Каждый ресурс представляет из себя LSB/OCF скрипт, который должен обрабатывать минимум три параметра: start,stop,monitor, выдавая корректные коды возврата.

Управление ресурсами осуществляется через команду crm resource:

crm resource stop resource1 - остановить ресурс resource1
crm resource start resource1 - запустить ресурс resource1
crm resource move resource1 node2 - принудительно переместить ресурс resource1 на node2
crm resource cleanup resource1 - удалить счетчики сбоев ресурса resource1 со всех узлов
crm resource cleanup resource1 node2 - удалить счетчики сбоев ресурса resource1 с узла node2
crm resource help - справка по доступным действиям

Создание ресурсов осуществляется через crm configure primitive … .

Создание ресурса веб сервера apache из скрипта OCF apache осуществляется командой:

crm configure primitive sites-httpd ocf:heartbeat:apache params \
configfile="/cluster/conf/httpd-sites/conf/httpd.conf" httpd="/usr/sbin/httpd" port="85" \
statusurl="http://127.0.0.1:85/server-status" testregex="Apache" op monitor interval="30s"

Где

• sites-httpd – имя ресурса
• ocf:heartbeat:apache – расположение скрипта ресурса. ocf – тип скрипта (ocf или lsb), heartbeat – набор скриптов heartbeat, apache – имя скрипта. OCF скрипты располагаются в /usr/lib/ocf.
• configfile, httpd, port, statusurl, testregex – набор параметров OCF скрипта. Их имена, семантика и использование индивидуальны для каждого скрипта.
• op monitor interval=»30s» – применять к скрипту операцию monitor каждые 30 секунд. В случае если скрипт ocf::apache monitor вернул статус отличный от нуля, осуществляется попытка потушить ресурс и поднять его снова. При определенном количестве сбоев осуществляется решение о перемещении ресурса на другой узел.

Апач очевидно необходимо повесить на определенный IP адрес. По этому необходимо создать ресурс IP адреса:

crm configure primitive sites-ip-ext ocf:heartbeat:IPaddr2 \
        params ip="192.168.0.31" cidr_netmask="32" \
        op monitor interval="30s"

Однако очевидно что IP адрес и апач должны стартовать последовательно и на одном узле. Для определения таких связей используются Группы ресурсов

Группы ресурсов

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

Например, ресурсы веб-сервера Apache (sites-httpd) и IP адрес для него (sites-ip-ext). Это два ресурса. Очевидно, что Apache не поднимется, если в системе нет определенного для него IP адреса. По этому мы создаем группу sites:

crm configure group sites sites-ip-ext sites-httpd

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

Вес связи

Для установки предпочтений связей используется вес связей от -INFINITY до +INFINITY. Установка с весом -INFINITY или +INFINITY является жесткой. Вес +/- INFINITY не может оспариваться другими условиями. Вес в целочисленном представлении может.

location

Директивой location можно определить предпочтительный запуск определенного ресурса/группы на определенном узле.

Установка предпочтения запуска ресурса httpd с весом 50 на node1 и весом 100 на node2:

crm configure location httpd-prefer-node1 httpd rule 50: node1
crm configure location httpd-prefer-node2 httpd rule 100: node2

Установка жесткого запуска ресурса httpd сугубо на node1 (ахтунг! при сбое ресурса его миграция на другие ноды будет весьма затруднена!):

crm configure location httpd-prefer-node1 httpd rule INFINITY: node1

Ресурс httpd не должен вообще никогда запускаться на node2:

crm configure location httpd-prefer-node1 httpd rule -INFINITY: node2

colocation

Директивой colocation можно определить предпочтительный запуск определенных ресурсов/групп вместе на одном узле.

Запускать ресурсы WebSite ClusterIP только на одном узле

crm configure colocation website-with-ip INFINITY: WebSite ClusterIP

Никогда не запускать ресурсы nginx и apache на одном узле

crm configure colocation nginx-not-apache -INFINITY: nginx apache

Установка

Нужно убедиться что:

• IP и hostname ноды взаимно отвечают друг другу в DNS на A и PTR запросы.
• Настроена ssh авторизация по публичному ключу текущей ноды со всеми остальными, всех остальных с текущей и текущей с текущей
• SELinux выключен
• Временная зона на всех нодах одинакова и время синхронизировано

Подключаем репозиторий ClusterLabs и устанавливаем софт:

cd /etc/yum.repos.d
wget http://www.clusterlabs.org/rpm/epel-5/clusterlabs.repo
yum install pacemaker corosync openais

Содержимое файла /etc/corosync/corosync.conf:

# Please read the corosync.conf.5 manual page
compatibility: whitetank
 
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.0.0
                mcastaddr: 239.192.1.1
                mcastport: 4000
#               broadcast yes
        }
}
 
logging {
        fileline: off
        to_stderr: no
        to_logfile: yes
        to_syslog: yes
        syslog_facility: local2
        logfile: /var/log/corosync.log
        debug: off
        timestamp: on
        logger_subsys {
                subsys: AMF
                debug: off
        }
}
 
amf {
        mode: disabled
}

Где:

• bindnetaddr – Сеть класса С для внутренних коммуникаций, это не IP адрес ноды, это сеть /24, в котором он находится
• mcastaddr, mcastport – адрес и порт для мультикастовых сообщений

Файл /etc/corosync/authkey суть случайная последовательность байт длинной около 128 байт, должен быть одинаковый для всех нод кластера. Следовательно, для первой ноды кластера мы его создаем

dd if=/dev/urandom of=/etc/corosync/authkey bs=1 count=128
chmod 600 /etc/corosync/authkey

А для остальных нод кластера мы его просто копируем.

Файл для связки corosync & pacemaker /etc/corosync/service.d/pcmk:

service {
        # Load the Pacemaker Cluster Resource Manager
        name: pacemaker
        ver:  0
}
END

Стартуем:

/etc/init.d/openais start
/etc/init.d/corosync start
chkconfig opeais on
chkconfig corosync on

Убедиться что кластер стартовал можно командой crm status.

Написано по мотивам Linux HA на основе Pacemaker (значительно дополнил статью).

ATA Over Ethernet (ATAoE,AoE,aoe) — протокол доступа к блочным SATA/SAS устройствам напрямую через транспорт Ethernet. Предназначен для организации бюджетного Storage Area Network (SAN) в пределах одного Ethernet сегмента.

Разработкой и поддержкой протокола занимается компания Coraid
Структурно состоит из «сервера» (Taget’а) и «клиента» (Initiator’а).

Почему ATAoE?

Мой выбор пал на ATAoE прежде всего из-за топорной своей простоты и элегантности, сочетающейся с производительностью и стабильностью. Как известно, чем проще протокол, тем меньше в нем потенциальных глюков.

На протоколе ATAoE можно очень быстро поднять сторедж или его клиент под любым линуксом.

ATAoE работает на уровне Ethernet и не использует TCP стек и его накладные расходы вообще. Что касается авторизации, присутствует фильтр по MAC адресам.

Конечно, у iSCSI больше свистелок и перделок чем в ATAoE. Но они в моих задачах не нашли применения. Авторизация в пределах одного Ethernet сегмента не нужна, ибо я в силах обозвать свой сегмент безопасным. Протокол TCP ни к чему, ибо я еще не дошел до маразма гонять ATA команды через глобальные сети.

Я честно не знаю как данный протокол работает на других системах. Говорят, драйверы есть. Но в мои задачи входили только линуксы, а там он работает идеально.

ATAoE Target

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

При настройках экспорта указываются номера «Shelf» и «Slot». Shelf — порядковый номер компьютера или стораджа, на котором находится блочное устройство, Slot — порядковый номер блочного устройства. Например, номер ATAoE устройства 1.2 говорит о том, что блочное устройство располагается на сервере (shelf) с порядковым номером 1 под порядковым номером (Slot) 2.

В ОС GNU/Linux представляет из себя user-space GPL-демона vblade из пакета aoetools. vblade может экспортировать любое блочное устройство, как то диск, партицию, устройство md или LVM logical volume. Так же vlbade может экспортировать файл заданного размера на файловой системе как блочное устройство.

Так же, Coraid поставляет готовые к использованию хардварные стораджи, выступающие в качестве AoE Target в сегменте Ethenet. Они работают под управлением OS Plan9, для доступа к ним по Ethernet необходима GPL утилита «Coraid Ethernet Console» или «cec» из пакета aoetools.

ATAoE Initiator

Клиентская часть AoE, представляет из себя драйвер, позволяющий импортировать расшаренные в Ethernet сегменете диски (AoE targets).

В ОС GNU/Linux представляет из себя модуль ядра aoe, входящий в ванильное ядро Linux. Однако для корректной работы модуля и использования последних нововведений рекомендуется обновлять драйвер aoe из пакета aoetools до последней версии (при каждом обновлении версии ядра).

Импортированные диски видны в системе в директории /dev/etherd/ с именами «eN.M», например /dev/etherd/e1.0. Где N — номерShelf, M — номер Slot.

При этом, если устройство eN.M имеет главную таблицу разделов, то соответствующие партиции будут видны как/dev/etherd/eN.Mp1, /dev/etherd/eN.Mp2 и т.д.

Установка AoE Initiator под OS GNU/Linux

Программные требования:

• OS CentOS >=5 (можно и любой другой Linux, но описанный способ использует CentOS)
• Ядро из стандартной ветки
• RPM: kernel-headers, kernel-devel, make, gcc

Требования по железу:

• 1Gbps Ethernet
• Желательно, выделенный Ethernet-сегмент для коммуникаций с AoE Targets
• Желательно, сетевая карта с поддержкой Jumbo Frames на Initiator’е и Target’ах, свитч с поддержкой Jumbo frames, Ethernet кабель категории 6

Качаем aoeX-YY.tar.gz, распаковываем.

Делаем make install.

Для корректной загрузки драйвера при старте, имеется RC-скрипт. Он загружает модуль, конфигурирует MTU и txqueuelength на сетевом интерфейсе, и делает поиск сетевых дисков:

#!/bin/bash
#
# aoe          Start/Stop the aoe.
#
# chkconfig: 3 15 30
# description: Starts/Stops AOE Initiator for GPFS
# processname: aoe                                        
 
# Source function library.
. /etc/init.d/functions
 
prog="aoe"
t=/usr/bin/test
 
if [ -f /etc/sysconfig/$prog ]; then
    . /etc/sysconfig/$prog
fi
 
start() {
        echo $"Starting $prog."
        echo -n $"Checking aoe not loaded"
        s=`/sbin/lsmod | /bin/grep aoe | /bin/grep -v grep`
        if $t -n "$s" ; then
            failure
            echo
            return 1
        fi
        passed
        echo
 
        echo -n $"Configuring $AOE_IF"
 
        /sbin/ifconfig $AOE_IF txqueuelen $AOE_IF_TXQ mtu $AOE_IF_MTU up
        RETVAL=$?
        if [ $RETVAL -ne 0 ]; then
            failure
            echo
            return 1
        fi
 
        passed
        echo
 
        echo -n $"Loading aoe module...."
        /sbin/modprobe aoe aoe_deadsecs=$AOE_TIMEOUT aoe_maxsectors=$AOE_MAXSECTORS aoe_iflist=$AOE_IF aoe_maxout=$AOE_MAXOUT
        RETVAL=$?
        if [ $RETVAL -ne 0 ]; then
            failure
            echo
            return 1
        fi
 
        passed
        echo
 
        # Give some time to identiy devices
 
        echo -n $"Prepare for discover...."
 
        num1=0
        while [ ! -c /dev/etherd/discover ]; do
            sleep 1
            num1=$(($num+1))
            if [ $num1 -gt 60 ]; then
                echo -n $"timeout $num1"
                failure
                echo
                return 1
            fi
        done
 
        passed
        echo
 
        echo -n $"Waiting for devices...."
 
        /usr/sbin/aoe-discover
        num=0
# Здесь необходимо дождаться появления определенного блочного устройства - изменить на свой вкус
#        until [ -b /dev/etherd/e1.0 ]; do
        until [ -d /dev/etherd ]; do
            sleep 1
            num=$(($num+1))
            if [ $num -gt 60 ]; then
                echo -n $"timeout $num"
                failure
                echo
                return 1
            fi
            /usr/sbin/aoe-discover
        done
 
        passed
        echo
 
        touch "/var/lock/subsys/$prog";
        echo -n $"AOE driver initialization complete"
        success
        echo
        return 0
 
}
 
stop() {
        echo -n $"Stopping $prog: not supported"
        success
        echo
        return 0
}
 
rhstatus() {
        status $prog
}
 
restart() {
        stop
        start
}
 
case "$1" in
  start)
        start
        ;;
  stop)
        stop
        ;;
  restart)
        restart
        ;;
  status)
        rhstatus
        ;;
  condrestart)
        [ -f "/var/lock/subsys/$prog" ] && restart || :
        ;;
  *)
        echo $"Usage: $0 {start|stop|status|restart|condrestart}"
        exit 1
esac

Скрипт автозагрузки требует конфигурационный файл /etc/sysconfig/aoe:

# IO Timeout
AOE_TIMEOUT=180
# Max Sectors Per single IO
AOE_MAXSECTORS=4096
# AOE Interface
AOE_IF=eth2
# Interface txqueuelen
AOE_IF_TXQ=5000
# Interface MTU
AOE_IF_MTU=4200
# AOE Sleep settle
AOE_SLEEP=4
AOE_MAXOUT=100

Где

• AOE_TIMEOUT — таймаут в секундах ожидания ответа от Target, после которого выдается ошибка IO.
• AOE_IF — интерфейс, который смотрит в сегмент Ethernet с AoE Targets.
• AOE_IF_TXQ — txqueuelength для AOE_IF
• AOE_IF_MTU — MTU для AOE_IF
• AOE_SLEEP,AOE_MAXOUT,AOE_MAXSECTORS — недокументированные параметры, подсказанные мне поддержкой Coraid, для моего случая.

После чего, включаем aoe в автозагрузку:

chkconfig --add aoe

И пробуем:

/etc/init.d/aoe start

Jumbo frames

Для продуктивной работы ATAoE требуется установить MTU на транспортном сетевом интерфейсе в 4200, а txqueuelength (OS GNU/Linux) в 5000.

Установка MTU в значение >1500 называется «поддержкой Jumbo frames»

Далеко не все сетевые карты поддерживают jumbo frames, по этому перед установкой необходимо убедиться в том, что карта поддерживает эту возможность. Сделать это можно командой:

ifconfig eth2 mtu 4200

Если команда выполнена без ошибок, то все в порядке.

Jumbo frames должен поддерживать как Initiator так и Target. Кроме того, jumbo frames должен поддерживать еще и свитч. Т.е. jumbo frames должны поддерживаться на всем пути от Initiator до Target, иначе они не имеют смысла.

Обновил vsftpd до последней актуальной версии 2.3.4-ext1. Теперь можно в vsftpd.conf задать локальную кодировку и кодировку клиента, например так: convert_charset_enable=1 local_charset=UTF8 remote_charset=CP1251 Включить механизм против подбора паролей. Введены параметры anti_bruteforce (по-умолчанию выключен) и anti_bruteforce_banner (по-умолчанию пустая строка). anti_bruteforce=1 anti_bruteforce_banner=Bruteforce detected. Server in safe mode. Расширена работа с HTTP частью сервера. В настройках появились такие переменные [...]

Вышел RHEL 5.6 список изменений

На DNS сервер запускаем dnstop dnstop -4 -Q -i IP_АДРЕС ВАШЕГО_DNS eth0 Queries: 736 new, 163198 total Tue Dec 21 10:43:03 2010 Sources Count % -------------- --------- ------ 172.17.61.58 15479 9.5 172.17.17.10 2273 1.4 172.16.210.14 2058 1.3 172.16.250.158 972 0.6 172.17.3.218 761 0.5 172.19.179.211 748 0.5 172.17.24.58 688 0.4 172.16.13.202 625 0.4 172.16.184.6 557 0.3 [...]