SysAdmins Location

Установил на сайт плагин для wordpress по интеграции с сервисом Loginza, теперь на сайте доступна авторизация при помощи всех популярных интернет сайтов и социальных сетей, таких как google, vk.com, yandex и т.д.

В итоге оставлять комментарии или общаться стало чуть проще.

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

Исходный код

[2640927.170015] aacraid: Host adapter abort request (0,0,0,0)
[2640927.170089] aacraid: Host adapter reset request. SCSI hang ?

Так как во время возникновения данной ошибки в виртуальных машинах, которые работали на данных серверах, подскакивал LA до 50-80, то данная проблема ощутимо сказывалась на работе всей инфраструктуры в целом.

В результате анализа были предложены следующие меры:

1) Обновить драйвера для контроллеров до версии 29900. Так как в ядре 2.6.32, которое используется в Debian 6, стояли очень старые драйвера версии 28800.

Также судя по changelog`у некоторые исправления в теории могли косвенно устранить возникающую проблему.

Firmware на самих контроллерах было уже обновлено до последней стабильной версии.

2) Поставить дополнительную систему охлаждения на RAID контроллера.

Судя по официальным рекомендациям температура RAID контроллера серии 6805 должна быть в районе 55 градусов в рабочем режиме, на обоих серверах температура была в диапазоне от 66 до 76 градусов, что намного выше нормы.

По ждали систему охлаждения вынули заглушки для 3,5 дисков, которые еще не были установлены. В итоге, даже такие полумеры позволили снизить температуру обоих контроллеров на 5-10 градусов.

В течение недели в ДЦ привезли вот такую, штатную систему охлаждения для RAID контроллеров (закладка Модули доп. охлаждения), после установки которой температура на RAID контроллерах не поднимается выше 39 градусов.

В итоге проведенных работ, после перезагрузки серверов проблема больше не возникала.

Ниже график из системы мониторинга Zabbix, с температурными данным до установки дополнительной системы охлаждения и после:

Знакомый обратился с вопросом — как сбросить утерянный пароль для форума IPB 2.x. В итоге небольшого анализа оказалось, что IPB хранит пользователей в базе в таблице ibf_members, а вот пароли для них в таблице ibf_members_converge.

Формат таблицы:

Исходный код

mysql> select * from ibf_members_converge limit 0,1;
+-------------+-------------------------+-----------------+----------------------------------+--------------------+
| converge_id | converge_email          | converge_joined | converge_pass_hash               | converge_pass_salt |
+-------------+-------------------------+-----------------+----------------------------------+--------------------+
|           1 | tt@gmail.com |      1206355019 | 84169616fd7f528b45f9e752ad5262eb | SLT$               |
+-------------+-------------------------+-----------------+----------------------------------+--------------------+
1 row in set (0.00 sec)

Где converge_pass_hash — md5 хеш от содержимого converge_pass_salt и того пароля, который был задан.

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

Исходный код

<?php
$salt=trim('SLT$');
$pass=trim('supertest123');
echo md5(md5($salt).md5($pass))
?>

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

Исходный код

UPDATE ibf_members_converge SET converge_pass_hash = '3d0a3d43c812e64b258974661231a57a', converge_pass_salt = 'SLT$' WHERE converge_id='1';

После чего авторизоваться в админке с паролем supertest123.

Недавно столкнулся с проблемой, на одном из 2-х практически идентичных серверов операции записи в memcachedb выполнялись раз в 10 медленнее.

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

Dmesg на проблемном сервере показал нам следующее:

Исходный код

[    1.581114] sd 2:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[    1.581170] sd 2:0:0:0: [sda] Write Protect is off
[    1.581172] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.581199] sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    1.581355]  sda:
[    1.581407] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[    1.581455] sd 3:0:0:0: [sdb] Write Protect is off
[    1.581457] sd 3:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    1.581475] sd 3:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    1.581623]  sdb:

Судя по словам «Write cache: disabled», при загрузке выключается кеш на запись данных, по результатам в BIOS действительно оказался выставлен ATAPI Write Cache — Disabled, а также режим работы SATA дисков был выставлен в IDE, а не AHCI.

После изменения данных параметров все заработало корректно.

Не так давно столкнулся со следующей проблемой — есть банк клиент, он написан на Java. После миграции одного из офисов с ISA 2006 на TMG 2010 возникла проблема, а именно постоянно наблюдались тормоза в интерфейсе банк клиента, переход между меню, формирование запросов происходило по 10-15 минут.

В ходе анализа сетевого трафика было выяснено следующее — TMG 2010 до SP2 не соответствует RFC 793, а именно после разрыва соединения, когда клиент и сервер обменялись FIN-ACK, ACK — TMG 2010 все равно продолжал использовать тот же порт исходящего соединения что и в уже разорванной сессии. В итоге оборудование Cisco не давало установить повторное TCP соединение пока не истечет установленный в RFC timeout, и банк клиенту приходилось каждый раз переустанавливать TCP соединение после запроса какого-нибудь элемента в его интерфейсе. От чего и появлялись такие дикие проблемы в его работе.

Лог сетевого трафика, который был получен при анализе:

Исходный код

Где-то выше установили соединение, запросили какие-то данные в интерфейсе банк клиента:
 
54565 12:51:31.086843 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [ACK] Seq=41 Ack=338 Win=65198 Len=0
54569 12:51:31.089041 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [ACK] Seq=41 Ack=338 Win=65198 Len=536
54570 12:51:31.089041 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [ACK] Seq=577 Ack=338 Win=65198 Len=536
54571 12:51:31.089424 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [ACK] Seq=1113 Ack=338 Win=65198 Len=536
54572 12:51:31.089424 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [ACK] Seq=1649 Ack=338 Win=65198 Len=536
54573 12:51:31.089460 195.91.x.x -> 87.245.x.x TCP 31294 > 9091 [ACK] Seq=338 Ack=1113 Win=64423 Len=0
54574 12:51:31.089711 195.91.x.x -> 87.245.x.x TCP 31294 > 9091 [ACK] Seq=338 Ack=2185 Win=65535 Len=0
54575 12:51:31.094693 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [FIN, PSH, ACK] Seq=2185 Ack=338 Win=65198 Len=258
54576 12:51:31.094901 195.91.x.x -> 87.245.x.x TCP 31294 > 9091 [ACK] Seq=338 Ack=2444 Win=65277 Len=0
54582 12:51:31.096598 195.91.x.x -> 87.245.x.x TCP 31294 > 9091 [FIN, ACK] Seq=338 Ack=2444 Win=65277 Len=0
54584 12:51:31.102534 87.245.x.x -> 195.91.x.x TCP 9091 > 31294 [ACK] Seq=2444 Ack=339 Win=65198 Len=0
(Получили какой-либо элемент в банк клиенте и разорвали соединение по запросу со стороны банка)
 
54590 12:51:31.104648 195.91.x.x -> 87.245.x.x TCP [TCP Port numbers reused] 31294 > 9091 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
(Послали запрос на переустановку соединения с того же порта, что и предыдущая сессия)
 
59034 12:51:34.020847 195.91.x.x -> 87.245.x.x TCP 31294 > 9091 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
66893 12:51:40.036479 195.91.x.x -> 87.245.x.x TCP 31294 > 9091 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
(Не получили ответа от оборудования банка в течение 10 секунд, в итоге TCP сессия не установилась и в интерфейсе банк клиента у бухгалтеров возникли «тормоза»)
 
82356 12:51:52.177898 195.91.x.x -> 87.245.x.x TCP 30993 > 9091 [SYN] Seq=0 Win=65535 Len=0 MSS=1460
82367 12:51:52.182222 87.245.x.x -> 195.91.x.x TCP 9091 > 30993 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460
(Так как установка прошлого TCP соединения не удалась, перезапустили установку TCP соединения по новой)
 
82368 12:51:52.184245 195.91.x.x -> 87.245.x.x TCP 30993 > 9091 [ACK] Seq=1 Ack=1 Win=65535 Len=0

По идее исправление http://support.microsoft.com/kb/2596065/en-us, которое входит в SP2 должно было решить проблему, но на практике наблюдается следующее поведение:

1) При создании ключа ApplyCooldownForLocalSourcePortReuseValue = 1 и последующей перезагрузке сервера с TMG 2010  процесс Microsoft Firewall запускался, но иногда переставал пропускать через себя трафик. Такое происходило редко, но все равное неприятно.

2) При создании ключа CooldownForLocalSourcePortReuseTime процесс Microsoft Firewall запускался, но иногда переставал пропускать через себя трафик в любом случае.

При этом все равно, даже с созданным ключом ApplyCooldownForLocalSourcePortReuseValue = 1 через какое-то время работы, где то 5-7 дней прежнее поведение банк клиента возвращалось и проблему удавалось решить только повторной перезагрузкой.

Недавно, при установке Backup Exec 2010 столкнулся с проблемой, а именно не устанавливался SQL 2005 Express сервер с ошибкой:

V-225-53: ERROR: Failed to install SQL Express BKUPEXEC instance with error 29508

Забегая вперед скажу, что проблема возникла из-за неправильной установки ОС на сервер прошлым администратором. Получается после установки сервера, поднятия на нем роли домен контроллера и SQL сервера администратор заметил, что забыл его переименовать.

В KnowledgeBase компании Symantec вычитал о следующих решениях проблемы:

http://www.symantec.com/docs/TECH128918

http://www.symantec.com/docs/TECH71380

По сути пришлось применить оба решения сразу, то есть, так как сервер ставился на контроллер домена в виду того, что у данной компании сервер один, в оснастке Active Directory Users And Computers в OU Users все записи начинающиеся с SQLServer2005MSSQLUser должны быть приведены к виду SQLServer2005MSSQLUser$serverName$databaseName. Где serverName — название сервера, без каких либо постфиксов, например просто server, а не server.domain.local.

В реестре же пришлось не только править параметр OriginalMachineName, который указан в статье, но и искать все записи в реестре, которые содержат старое название сервера до его переименования, анализировать для чего они созданы и если есть возможность — исправлять на текущее имя сервера.

После перезагрузки установка Backup Exec 2010 прошла без проблем.

Давно не писал в блог, все связанно со сменой работы.

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

Позднее опишу сделанные мною выводы.

Интересное видео со встречи Петра Зайцева из Percona в компании mail.ru, есть некоторая интересная информация по теме оптимизации работы mysql. Рекомендую для просмотра всем системным администраторам.

Интересный цикл статей описывающий проблемы с буферизацией в современных высокоскоростных TCP/IP сетях. Рекомендую к прочтению всем системным администраторам.