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

Собрал всё на новом месте - один сервер не запустился. Сервер старый - 12 лет, ещё на SAS дисках 10k формата SFF (2.5") и железном контроллере LSI MegaRAID. Вот он то и подвёл. Просто перестал определятся. Соответственно, сам сервер работает, но диски не видит. Я и так, и сяк его покрутил, повертел, потряс, повтыкал - ничего не помогает. Сервер хоть и старый, но жаль его, свою работу он выполнял, и его 8 дисков в одном юните были очень кстати.

Это известная тема, когда выходит из строя рейд контроллер. Её всегда приводят в пример, когда спорят на тему, нужен ли он, или лучше использовать программную реализацию. Конкретно в этом споре мне довод о том, что рейд контроллер может сломаться, кажется нелепым. Сломаться может всё, что угодно. В любом случае должны быть бэкапы, чтобы не переживать за железо. У меня бэкапы были, уже развернул. Не без приключений, но всё получилось. Отдельно об этом расскажу.

Для меня выбор между железным рейдом и софтовым даже сейчас не очевиден. Да, рейд контроллер - это ещё одна точка отказа и его функциональность почти полностью может заменить программный рейд. Но в то же время отвязка системы хранения от ОС с управлением и мониторингом через BMC (Baseboard Management Controller), плюс, простая и понятная горячая замена дисков, тоже выглядят удобным. Если всё нормально настроено, сбойный диск просто начинает мигать красным. Ты его вынимаешь, заменяешь и запускается ребилд, либо диск встаёт в резерв, а ребил уже был выполнен резервным диском. Всё максимально просто, даже сервер выключать не надо.

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

По поводу переезда серверов лишний раз хочу напомнить, что если выключаете, а тем более перевозите оборудование, которое много лет работает онлайн, всегда держите в голове, что что-то может не включиться. Я много раз с этим сталкивался. Чем старее железо, тем больше вероятность, что оно не включится. И хорошо, если будет понятно, что вышло из строя, а это не всегда так. Там банально пластик пересыхает в проводах, пропадает контакт или становится нестабильным.

Конечно, хорошо полностью отвязаться от железа и арендовать облачные ресурсы. Но если взять, к примеру, этот сервер, который проработал 12 лет, и арендовать эти же ресурсы в облаке на такой же срок, то не ошибусь, если предположу, что расходов будет на порядок больше - раз в 10-20.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#железо

🫣 Вы ведь не переносите вручную данные из сервис деска в другую систему и обратно, правда?

4 июня в 11:00 МСК приглашаем на вебинар

«Как подружить ITSM 365 с другими сервисами: 4 способа настройки интеграций под ваши задачи»

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

А нам есть что предложить: 3 базовых варианта и 1 альтернативный способ.

📶 Готовые интеграции — легко подключить, просто управлять

📶 Интеграции через JSON RPC — для тех, кто хочет сделать сам

📶 Настройка вендором — мы реализуем, вы пользуетесь

📶 Реализация с помощью low-code платформы — весь процесс внутри ITSM 365, без всяких там внешних сервисов

Приходите, расскажем в подробностях!

🔗 Зарегистрироваться на вебинар

Реклама, ООО Смартнат, ИНН 6658396257, erid: 2SDnjevC3xe

И в продолжение утренней темы про переезд серверной. Как уже сказал, один из серверов не завёлся. Там был гипервизор Hyper-V. Раньше я постоянно использовал его бесплатную редакцию, потому что удобно и много инструментов для бэкапов. Последние несколько лет ставлю везде Proxmox. Тут поленился сделать заранее переезд на новый гипервизор, за что и поплатился.

С виндовым терминальным сервером пришлось повозиться. В общем случае переезд с Hyper-V на Proxmox у меня выглядел просто:

1️⃣ Импортировал VHDX образ диска из Veeam Backup & Replication в файл.
2️⃣ Подмонтировал в Proxmox шару с файлом и забрал на гипервизор.

# mount -t cifs //192.168.0.7/backup /mnt/fileserver -o user=backup,password=pass123

3️⃣ Создал новую машину в PVE без дисков.
4️⃣ Сконвертирал и сразу подключил диск к новой машине:

# qm importdisk 107 /mnt/fileserver/terminal.vhdx local

Формат команды следующий:

# qm importdisk <vmid> <source> <storage>

Система была без EFI, так что никаких лишних заморочек. Но дальше начались свои приключения, с которыми пришлось разбираться, так как у меня почти нет практики восстановления Windows. Если в Linux мне всё понятно - загрузчик grub, стартовый образ initramfs и дальше основная система, то винда - тёмный лес. Хорошо, что для таких случаев есть ИИ, который хоть и не давал точных ответов без ошибок, но направление было понятно.

В системе не было драйверов virtio, соответственно, система не загрузилась, потому что загрузчик не нашёл диск, с которого надо грузиться. Дальше в целом понятно, что надо делать, но когда ты делаешь это в первый раз, возникает очень много нюансов, а основное неудобство в том, что работать приходится с консолью виртуальной машины, в которой не работает копирование и вставка. Всё приходилось набирать руками. И до кучи в здании не было интернета, потому что туда провели оптику, вроде как всё проверили, но когда я заехал по факту был обрыв волокна. Приехал по заявке монтажник почему-то без оборудования для варки, потому что подумал, что повреждён оптический патчкорд. В общем, всё как обычно 😱

Рассказываю суть, как чинить загрузку Windows систем при переезде в Proxmox, если про какой-то причине вы заранее не установили туда драйвера.

1️⃣ Загружаемся в режиме восстановления и запускаем cmd.
2️⃣ Запускаем diskpart, вводим команду list volume, чтобы узнать букву диска, где стоит система, и букву диска с драйверами virtio. Диск с Windows VirtIO Drivers надо скачать и подключить к машине.
3️⃣ С помощью dism можно интегрировать в неработающую систему нужные драйвера (viostor для ide и vioscsi для scsi). Для меня это было новым знанием:

> dism /image:C:\ /add-driver /driver:D:\viostor\w10\amd64\viostor.inf

4️⃣ Далее оказалось, что интеграции драйверов недостаточно, их нужно то ли активировать, то ли добавить в загрузку. К сожалению, команд не сохранил, потому что смотрел их со смартфона. В общем, надо добавить ключ в реестр, чтобы драйвер загружался. Это тоже всё делается в cmd.
5️⃣ Опять с загрузкой провал. Система не грузится и ругается на неподписанный драйвер. Это ограничение можно обойти либо опять же командой в аварийной консоли, либо выбрав режим загрузки Windows, который есть в списке вместе с различными вариантами безопасной загрузки, который позволяет использовать неподписанные драйвера.
6️⃣ После всех описанных действий система загрузилась.

Всё это заняло много времени и может показаться, что путь нерациональный с точки зрения того, что ничего не было подготовлено заранее. У меня на самом деле был подменный сервер с Hyper-V, куда бы я мог всё восстановить, но раз уж случилось, решил сразу переехать на Proxmox, чтобы потом опять не заниматься этой задачей. По ходу дела уже думал развернуть бэкап на Hyper-V, установить драйвера и вернуть на PVE, но не захотелось по сети гонять огромный образ диска. Решил вопрос на месте.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#proxmox #hyperv

Решил вынести в отдельную заметку видео про Proxmox, которое мне показалось полезным, потому что некоторые советы из него я применяю сам, но никогда не собирал их в одну публикацию:

▶️ 5 полезных настроек Proxmox, которые стоит внедрить

Речь там идёт вот о чём:

1️⃣ Включить настройку Discard в свойствах диска виртуальной машины, если у вас хранилище на базе SSD дисков. По умолчанию она выключена.

Я всегда так делаю, а гостям в cron ставлю команду:

# fstrim -av

После её выполнения образ диска занимает ровно столько места, сколько реально занято в системе в госте, а не весь его объём. Это существенно экономит место на хранилище. Писал об этом подробную заметку.

2️⃣ Использование стандартных настроек CPU, которые поддерживаются всеми узлами кластера. Часто хочется указать тип host, и я так делаю, чтобы использовать все возможности ядра. Но в таком случае миграция не работает, если у вас узлы кластера с разными процессорами. Придётся установить что-то, что поддерживается всеми, типа x86-64-v2-AES, x86-64-v2 или kvm64. Тут уже по месту смотрите, из чего у вас собран кластер.

3️⃣ Автор предлагает использовать SDN вместо ручных настроек сети даже в самых простых ситуациях. Совет, конечно же логичный, но я пока костылю настройки сам без SDN. Надо бы переучиваться для унификации и переносимости.

4️⃣ Динамическая балансировка нагрузки в кластере. Она появилась в свежей версии 9.2 и автор предлагает её использовать. Собственно, почему бы и нет. Лишнее напоминание тем, кто пропустил новости с обновлением.

5️⃣ Последний совет на любителя - использовать различные панели управления и визуализации, типа Pulse или PegaProx. Я Pulse в пару мест поставил, где несколько хостов PVE. Выглядит красиво и удобно, но не сказать, что сильно надо. Можно и обойтись.

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

◽️Сразу через веб интерфейс отключаю enterprise репозиторий
◽️Готовлю простенький шаблон с системой для раскатки через cloude-init.
◽️Если не будет настраиваться ограничение доступа к веб интерфейсу через файрвол, то делаю его в настройках pveproxy через указание доверенных IP.
◽️Настраиваю отправку уведомлений (email, gotify)
◽️Если используется zfs, настраиваю лимит использования памяти

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#proxmox

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

Помню, что была опция по обновлению биоса в IPMI панели управления сервером. Захожу в Maintenance, нахожу BIOS Update и расстраиваюсь, так как для этого нужно приобретать какую-то лицензию. А без неё обновление только с загрузочного носителя в DOS или через UEFI. Очень не хотелось со всем этим заморачиваться, поэтому решил поискать путь попроще.

И я его нашёл. Есть репозиторий supermicro-product-key. Там работающее решение по получению ключа для разблокировки расширенных возможностей IPMI. Я его проверил, способ рабочий. У меня получилось без проблем обновить bios.

Для получения самой простой лицензии, которая позволяет обновлять биос, достаточно запустить генератор ключа на основе mac адреса сервера, который можно посмотреть в IPMI панели:

> supermicro-product-key.exe oob encode 3cecef123456
CE27-F641-9B04-6B24-5D04-5D32

Вводим код и можно обновлять биос. Я чисто из любопытства установил и самую навороченную лицензию, которая позволяет выполнять централизованное управление всеми серверами. В репозитории есть все инструкции. На практике не знаю, где это может пригодиться. У меня нету парка однотипных серверов. А вот обновление биоса очень пригодилось. Плюс, какой-то уровень лицензии добавил iKVM через HTML5, а не через глючную Java. Приятный бонус.

С учётом того, что серверы Supermicro за их стоимость довольно популярны у нас, решил написать заметку. Хотя лично я, если нужно приобрести сервер, отдаю предпочтение бушным серверам Dell.

Я заодно и прошивку IPMI обновил. И по старой русской традиции не прочитал инструкцию по обновлению. А там красным цветом с восклицательным знаком написано, что во время обновления надо поставить галочку на сброс настроек к заводским. Конечно же я этого не сделал. Мне и в голову не пришло, что это обязательное требование. В процессе был выбор - сбросить или оставить настройки. Разумеется, я оставил. Нелогично же давать выбор, когда выбора реально нет, надо обязательно сбрасывать.

В общем, после обновления IPMI он у меня сломался. Пришлось повозиться и через SUM (Supermicro Update Manager) сбросить настройки. Сервер старый, запасной, поэтому я поленился заморочиться и всё проверить. Но если будете рабочие сервера обновлять, то рекомендую всё же читать инструкции по обновлению как биоса, там и bmc.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#железо