Що перевірити на новому сервері, перш ніж він понесе продуктивне навантаження
Приймальні перевірки нового dedicated server: пам’ять, накопичувачі, кеш RAID, виявлення flash, агреговані лінки, подвійне живлення і віддалений доступ, з командами.

Новий dedicated server зазвичай приходить з операційною системою, логіном і припущенням: що все, за що ви заплатили, присутнє, справне і налаштоване для використання. Здебільшого це майже так. Розрив між «майже» і «повністю» є саме тим місцем, звідки беруться повільні бази даних, простоюючі мережеві лінки і несподівані збої. Ось приймальна перевірка, на яку, на нашу думку, заслуговує кожен сервер, перш ніж він понесе продуктивне навантаження, з командами, щоб провести її самостійно.
Чому приймальне тестування пропускають
Сервер, який завантажується, виглядає готовим. Операційна система не скаржиться на модуль пам’яті, якого не бачить, на кеш RAID, що працює без батареї, чи на bond, який відправляє кожен пакет одним лінком. Кожне з цього невидиме у звичайній роботі і дороге пізніше, і кожне перевіряється за хвилини в перший день. Після запуску ті самі перевірки потребують вікна обслуговування.
Пам’ять: уся, збалансована, без помилок
Переконайтеся, що система бачить кожен модуль, який ви замовили, і що вони стоять у збалансованій розкладці по каналах пам’яті кожного процесора. Незбалансована розкладка працює, але повільніше, ніж мала б.
dmidecode -t memory | grep -E 'Size|Locator' | grep -v 'No Module'
free -h
ras-mc-ctl --errors
Виправлені помилки пам’яті в перші дні життя сервера є причиною замінити модуль зараз, поки це легко, а не дивиною, за якою варто спостерігати.
Накопичувачі та контролер RAID
Прочитайте стан кожного накопичувача, включно з тими, що сховані за апаратним контролером RAID, і стан кешу запису контролера:
smartctl -a /dev/sda
smartctl -a -d megaraid,0 /dev/sda # a drive behind a MegaRAID-family controller
storcli64 /c0 show all # Dell PERC and LSI family
ssacli ctrl all show config detail # HPE Smart Array
Шукайте ненульові лічильники перепризначених, очікуючих або медіа-помилок на будь-якому накопичувачі. Новий накопичувач з виправленою помилкою є накопичувачем, чия власна корекція помилок уже важко працює. На контролері переконайтеся, що логічний диск має замовлений рівень RAID, кеш у режимі write-back, а батарея або flash-модуль резервного живлення кешу звітують про справність. Контролер, який перейшов у write-through через свою батарею, може зробити так, що масив SSD відчуватиметься як диски, що обертаються.
Потім виміряйте пропускну здатність на порожньому томі до того, як він міститиме дані, інструментом на кшталт fio, щоб мати базовий рівень для порівняння пізніше.
Чи сприймається flash як flash?
Апаратні контролери RAID часто не передають ядру прапорець твердотільного накопичувача, тож том, зібраний з SSD, звітується як диск, що обертається, і отримує налаштування, підібрані для обертових носіїв:
lsblk -d -o NAME,ROTA,SCHED,MODEL
cat /sys/block/sda/queue/read_ahead_kb
Якщо ROTA показує 1 на томі, про який ви знаєте, що це flash, спершу підтвердьте тип носія з контролера, потім виправте це правилом udev, щоб воно переживало перезавантаження:
# /etc/udev/rules.d/60-ssd-tunings.rules
ACTION=="add|change", KERNEL=="sda", ATTR{queue/rotational}="0"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="mq-deadline"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/read_ahead_kb}="16"
ACTION=="add|change", KERNEL=="sda", ATTR{queue/nr_requests}="1024"
udevadm control --reload && udevadm trigger --action=change /sys/block/sda
Не застосовуйте це до тому на жорстких дисках. Короткий read ahead пасує flash і шкодить послідовному читанню з обертових носіїв.
Мережа: два лінки, обидва працюють
Сервер з двома агрегованими портами часто працює на одному з них. Типовий хеш передачі драйвера bonding у Linux дивиться лише на MAC-адреси, і в дата-центрі, де хост спілкується з жменькою MAC шлюзів і сусідів, це може покласти майже кожен потік на один і той самий лінк.
cat /proc/net/bonding/bond0
ethtool -S <first port> | grep -E 'tx_packets|rx_packets'
ethtool -S <second port> | grep -E 'tx_packets|rx_packets'
Перевірте, що обидва члени підняті, що LACP утворив пару з комутатором і що політика хешування така, як ви задумали. Під навантаженням лічильники обох членів мають рости схожими темпами. Для більшості серверів хешування за IP-адресами і портами розподіляє трафік значно краще:
nmcli con mod bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=slow,xmit_hash_policy=layer3+4"
Узгодьте з цим сторону комутатора, щоб трафік розподілявся однаково в обох напрямках. Потім витягніть один кабель, переконайтеся, що сервер залишається доступним, вставте його назад і повторіть з іншим.
Живлення, час і віддалений доступ
ipmitool sdr type "Power Supply"
chronyc tracking
getenforce
Обидва блоки живлення мають бути присутні і під напругою, і живитися від різних вводів. Сервер з двома блоками, увімкненими в один ввід, має одну точку відмови з додатковими кроками. Переконайтеся, що контролер позасмугового керування (iLO, iDRAC або IPMI) доступний у своїй мережі керування і ліцензований для віддаленої консолі, яка вам знадобиться. Якщо SELinux є частиною вашого стандарту, переконайтеся, що він у режимі enforcing до встановлення першого застосунку, а не після.
Запишіть це
Остання перевірка: документація. Серійний номер, позиція в стійці, кожен порт з його MAC-адресою і тим, куди він під’єднаний, кожна IP-адреса, обидва вводи живлення і ідентифікатори кабелів.
Як це робимо ми
Наші dedicated servers є платформами HPE ProLiant і Dell PowerEdge, з позасмуговим керуванням в ізольованій мережі. Кожна збірка RAID проходить перевірку стану накопичувачів і тест пропускної здатності перед передачею. Flash за контролером RAID отримує описане вище налаштування, прив’язане до типу носія, прочитаного з накопичувачів. Кожен bond хешує за адресами і портами, узгоджено на комутаторі. Ми перевіряємо лічильники кожного порту, щоб довести, що обидва лінки несуть трафік.
Якщо у вас є сервер уже в продуктивній роботі, який ніколи не проходив цієї перевірки, ще не пізно, і ми радо пройдемо її разом з вами.
Related
- /what-we-do/storage-compute/bare-metal-servers/
- /what-we-do/storage-compute/performance-engineering/
- /what-we-do/storage-compute/enterprise-san-storage/
Опубліковано 28 вересня 2026 р..
Усі нотатки з практики