Amazon EC2: обновление ядра linux в AMI

Одним из первых вопросов системных администраторов, которые начинают работать с сервисами Amazon, является: "а как обновить ядро в моем инстансе?".

До сравнительно недавнего времени ответ был один: "никак". Точнее, ядро можно было сменить, но только на одно из предоставляемых Amazon. Однако, ничто не стоит на месте. Появилось сразу два решения этой проблемы.

Первое: Амазон выпустил свой Amazon Linux (на базе RedHat Linux, но с массой изменений, в частности, kernel версии 3.х.х). В случае использования этого дистрибутива, проблемы нет вообще: обычное обновление инстанса через обычный yum с репозитариев Amazon.

Второе: Amazon наконец-то позволил обновлять ядра и сторонних дистрибутивов. Правда, не для запущенного инстанса, а для AMI, но все равно - это уже намного лучше, чем было. По крайней мере, если очень нужно, то можно сделать, хоть и с бОльшими трудозатратами.

Вот про этот второй способ я и расскажу.

Citrix XenServer: xe-edit-bootloader trick

Иногда нужен доступ в FS гостевой VM (domU). В Citrix XenServer сделано много изменений и фокус, как в обычном Xen тут не проходит.
Самый простой способ (разумеется, речь идет о linux с его FS):
Логинимся на сервер. Далее:
# xe-edit-bootloader -n MyVM -p 1
где MyVM - имя виртуальной машины, 1 - номер раздела, на котором находится /boot (я обычно выношу в отдельный небольшой раздел, первый)

Данная команда позволяет загрузить в текстовый редактор (и отредактировать, конечно) меню grub гостевой VM. Это полезная фича, но есть еще не менее полезное побочное действие: появляется доступ к виртуальному диску из dom0.
Важное примечание - VM должна быть остановлена, иначе ничего не получится.

Перенос виртуальных серверов VMware на XenServer для Linux guest

Как я уже писал в предыдущей статье мне придется переезжать с VMware. А что делать с виртуалками? Не переставлять же все - у меня их десятки, я полгода переносить буду (с учетом того, что их еще проверить нужно после переинсталляции).

Более логичным и правильным было бы перенести виртуалки через экспорт-импорт. Следует обратить внимание, что, если не соблюдать процедуру, а попытаться просто сделать экпорт виртуалки а потом ее импорт через XenConvert, виртуалка запуститься в HVM-режиме (полная виртуализация). Это-во-первых, замедлит работу виртуальной машины. Во-вторых, у меня обнаружилась бага - если на эту виртуалку подать сеть, подключенную через транк (VLAN) то внутри виртуалки сетевой интерфейс работает некорректно и пользоваться им невозможно.
Поэтому категорически рекомендую использовать паравиртуализацию.

Решение задачи есть на форуме Citrix, я воспользовался именно им, с небольшим уточнением.

Итак, приступим.

Я подразумеваю, что, раз уж админ пользовался VMware, то у него обязательно есть установленный Windows-хост, расположенный где-то рядом с гипервизорами. Тем более, что для CitrixXen понадобится XenCenter, который тоже написан под Windows.

Перво-наперво нам понадобиться пойти на сайт Citrix и вытащить свежую версию XenConvert. Нюанс заключается в том, что только самая последняя версия умеет корректно импортировать виртуалки с гостевой OS Linux (да и то - там все равно нужно делять ряд действий). Подходящая версия - на ниже 2.3.1.2654. Именно эта версия позволила мне произвести конвертацию.

Безотказная работа сети (network bonding) в Redhat - реализация(продолжение)

После статьи Обеспечение безотказной работы сети в RedHat Linux (bonding) для нескольких IP сетей прошло достаточно много времени, а тут мне (точнее начальству) приспичило сделать супер безотказную сетку :)

По "свежим следам", пока помню, опишу, т.к. задача была чуть более сложная, чем описано ранее, и как результат, проявились отличия.

Итак, постановка задачи:

• Имеем бокс с четырмя сетевыми картами подключенные к двум свичам


• Имеем две сети (два VLAN'а)


• Задача: пока жив хоть один свич и один порт, все должно работать :)

Собственно, задача ненамного сложнее, чем описанная в предыдущей статье про bonding.
Но есть и различия.

Subversion поверх HTTPS с авторизацией в LDAP - проблемы настройки искорости

Переезжаем на SVN. Всякие преимущества по сравнению с CVS расписывать не буду - в инете навалом.
Опишу несколько тонкостей и граблей, с которыми столкнулся.

Перво-наперво описание задачи.
Очевидные требования: криптование, централизованная авторизация.

После ряда размышлений остановился на связке SVN поверх HTTPS в связке с LDAP.

svn+ssh неудобно администрировать при большом количестве девелоперов и не-девелоперов, кому нужен доступ (анонимного доступа к репо нет)
Да и с LDAP там не так просто - на консоль сервера девелоперов пускать не стоит.

Первый этап - конфигурация Apache + SVN + LDAP. SSL коснемся отдельно - там закопаны здоровенные грабли. которые у меня отняли с неделю разборок :)

Tomcat 6 - включение APR и управление web приложениями

Ставил tomcat6. Возникла небольшая проблема - не активировался apr, в логах ошибка:

INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path

Простая доустановка libapr-1 ( пакет apr ) не помогает, tomcat все равно не хочет работать
Погуглил. Как-то все невнятно описано, пришлось глубже разбираться.

Изменение скорости линка адаптера Emulex (lpfc) в RHEL 5

Проявились проблемы на FC HBA. Поддержка HP запросила понизить скорость до 2Gbit на HBA адаптере.
Можно сделать как на лету, так и параметрами модуля.

Для модуля в /etc/modprobe.conf к строке options lpfc добавляем параметр lpfc_link_speed=N, где N может принимать значения 0,1,2,4,8.

0 - автоопределение (по умолчанию),
1,2,4,8 - заданная скорость порта

Для изменения "на лету" нужно воспользоваться sysfs. Даем команду
# echo N > /sys/class/scsi_host/hostM/lpfc_link_speed
где N принимает те же значения, что и для параметра модуля, а M - номер адаптера

PS. Посмотреть текущую скорость можно командой:
# cat /sys/class/fc_host/hostM/speed
а список поддерживаемых скоростей командой
# cat /sys/class/fc_host/hostM/supported_speeds

SAN storage - изменение размера диска (RHEL5)

Достаточно частая задача - увеличить размер диска, выделенного на SAN
Как правило ко мне с такой задачкой регулярно обращаются DBA, когда их база в очередной раз норовит заполнить выделенное пространство :)
Разумеется, никто не мешает поступить максимально просто - выделисть новый виртуальный диск на SAN, подключить его скопировать данные на новое место. Однако, для больших дисков (а для баз данных 100-200 гигабайт это вполне заурядный размер) это занимает массу времени. А если нужно проделать операцию для 2х-5ти серверов?

Гораздо быстрее будет увеличить виртуальный диск средствами SAN, а потом изменить размер FS средствами OS.
Делается это очень просто. Рассмотрим случай для RHEL 5

Определение WWN FC HBA адаптера в RHEL 5

Очень часто нужно быстро посмотреть WWN FC HBA адаптера (когда добавляешь хост в SAN)
И, как обычно, забываешь, где :)

Подсказка (для Emulex точно, для остальных похоже тоже :) ):

# cat /sys/class/fc_host/host0/port_name

Rescan SAN разделов - случай с multipath

Начиная с версии RHEL 5.3 и выше HP перестали делать свой драйвер multipulse и используют стандартный multipath.
Поэтому возникла проблема - схема рескана разделов , как описано ранее в статье уже не проходит. Как правило, данная задача нужна для resize (изменения размера) раздела (тома)

Теперь нужно действовать по следующей схеме (рассматривается случай с Emulex HBA, впрочем, с Qlogic будет почти также, изменятся только некоторые пути. У меня на блейдах по два адаптера, если их больше-меньше, будет небольшая разница в командах - по количеству адаптеров):

Памятка - как сделать custom RedHat iso образ

Памятка для себя - как сделать свою сборку RHEL с нужным набором rpm

RHEL (CentOS) подключаем к iSCSI storage

Может, кому полезно будет :)

Исходные условия:

RHEL5, на сетке NAS, который умеет отдавать iSCSI тома. Задача - подключиться к выделенному тому, доступ с авторизацией. Обычная задачка для кластеров (правда, в продакшн я использую SAN и доступ по оптике, но для тестирования и экспериментов - вполне годится, чтобы не расходовать дорогое дисковое пространство).

Итак, последовательность:

Некоторые результаты тестирования network teaming (bonding)

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

С помощью нашего нетворк инженера были проведены эксперименты, имитирующие проблемы с оборудованием. Точнее, просто отключали порты на свичах.

Краткие результаты:

• отключение второго порта (standby). Никаких изменений в работе сети, что и следовало ожидать.


• отключение первого порта (active). Сеть недоступна, в течении 30 сек происходит переключение, сеть снова доступна


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


• выключаем второй порт (текущий standby). переключение на основной линк произошло за несколько секунд.

Обеспечение безотказной работы сети в RedHat Linux (bonding) длянескольких IP сетей

Один из важнейших элементов обеспечения бесперебойной работы ответственных серверов ( работающих по схемам 24/7 или 365/24/7 ) это резервирование сетевых интерфейсов. В самом деле, какой смысл в дорогом оборудовании, RAID 1+0, spare disks, если сервер соединен со свичем через один адаптер, один кабель, один порт? Да и свич тоже может выйти из строя.

Пусть мы имеем следующие исходные параметры:

• сервер подключен к свичам через два адаптера


• в нашей сети имеются два диапазона IP адресов - 192.168.1.0/24 и 192.168.2.0/24


• эти сети разделены при помощи VLAN, ID сетей 10 и 20 соответственно


• адреса интерфейсов сервера - 192.168.1.10, 192.168.2.10


• ОС - RedHat 5 или совместимые - CentOS 5, Oracle Linux 5

Хочу обратить внимание. В данном примере (в отличие от классического варианта bonding) нам не нужно удваивать количество сетевых карт - мы будем использовать те, что есть (network teaming). Главное, что карт более одной.

CentOS 5.1 и D-Link Wifi

Столкнулся с серьезной проблемой.

Имеем WiFi: D-link Access Point DWL-2100AP и сетевушку D-Link DWL-G550 PCI на чипе Atheros AR5212

Сама сетевушка завелась без проблем (драйвер ath_pci), а вот коннектиться к точке доступа в упор не захотела. Притащил на работу. проверил на другой машине с AP Netgear - без малейших проблем запускается. С 2100AP - не хочет.

В общем, после танцев с бубнами перешили точку доступа на последнюю прошивку - полегчало, завелось сразу же, WPA2 поднялся без проблем на wpa_supplicant.