Подключение репозитория HP с системными утилитами

Management Component Pack

hp-health HPE System Health Application and Command line Utilities
hponcfg HPE RILOE II/iLO online configuration utility
hp-ams HPE Agentless Management Service
hp-snmp-agents Insight Management SNMP Agents for HPE ProLiant Systems
hpsmh HPE System Management Homepage
hp-smh-templates HPE System Management Homepage Templates
hpssacli HPE Command Line Smart Storage Administration Utility
hpssaducli HPE Command Line Smart Storage Administration Diagnostics
hpssa HPE Array Smart Storage Administration Service

Создаём файл с описанием репозитория /etc/yum.repos.d/mcp.repo:
[mcp]
name=Management Component Pack
baseurl=http://downloads.linux.hpe.com/repo/mcp/dist/dist_ver/arch/project_ver
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp

Где:
dist          centos, feodra, opensuse, oracle, asianux
   dist_ver      Browse repo to identify supported distribution versions
   arch          i386, x86_64,  amd64(debian/ubuntu)
   project_ver   current, 10.50, 10.40, 10.20, 10.00, 9.30, 9.25, 9.10 (Browse repo to identify supported project versions)

В моём случае (CentOS 6.8) получился вот такой файл:
[mcp]
name=Management Component Pack
baseurl=http://downloads.linux.hpe.com/repo/mcp/centos/6.8/x86_64/current
enabled=1
gpgcheck=0
gpgkey=file:///etc/pki/rpm-gpg/GPG-KEY-mcp


Посмотреть список пакетов из этого репозитория:
# yum --disablerepo="*" --enablerepo="mcp" list available


Установить пакет:
# yum install packagename
Например:
# yum install hp-health

Изменение параметров RAID-массива на контроллере HP Smart Array P440ar

Конечно, все возможности по изменению параметров RAID-массива я не рассматривал, у меня была конкретная задача. После добавления новых дисков я решил изменить тип массива с RAID5 на RAID1+0.
Управление контроллером осуществляется посредством утилиты hpssacli, операционная система — CentOS 7.2.

Вот первоначальное состояние:
=> ctrl slot=0 show config

logicaldrive 1 (838.3 GB, RAID 5, OK)

physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 450 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 450 GB, OK)
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 450 GB, OK)

unassigned

physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 450 GB, OK)
physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 450 GB, OK)
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 450 GB, OK)
physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 450 GB, OK)

Как мы видим у нас четыре неиспользуемых диска и RAID5-массив, который состоит из 3 дисков. Понятно, что изменить его тип на 1+0 не получится, но я должен был попробовать, чтобы посмотреть что получится:
=> ctrl slot=0 ld 1 modify raid=1+0

Error: «raid=1+0» is not a valid option for logicaldrive 1

Available options are:
0
5 (current value) (default value)

Всё логично )

Далее, как я понял, у меня два варианта действий:
1. добавить в существующий массив все неиспользуемые диски, а потом поменять его тип с 5 на 1+0;
2. добавить в существующий массив один неиспользуемый диск, потом поменять его тип с 5 на 1+0, а уж потом добавить в массив оставшиеся диски;

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

Так что я добавил в массив ещё один, четвёртый, диск:
=> ctrl slot=0 ld 1 add drives=2I:1:5

Процесс пошёл:
=> ctrl slot=0 show config

logicaldrive 1 (838.3 GB, RAID 5, Transforming, 2% complete)


Замечу, что система в это время работает нормально, никаких заметных торможений нет, правда нагрузку я с неё снял, чтобы процесс конвертации занял меньше времени. Кстати, у меня был опыт замены вышедшего из строя диска в массиве прямо во время работы достаточно нагруженного сайта. Во-первых, я не сразу заметил проблему и массив какое-то время работал в деградированном режиме, во-вторых, замену диска и последовавшую за этим перестройку массива пришлось проводить на ходу. Результат меня приятно удивил: никто ничего не заметил )

В документации сказано, что расширение, добавление или миграция логических дисков занимает примерно 15 минут на гигабайт. Я добавляю диск 450ГБ в массив 838ГБ. Рассчётное время по наименьшему варианту — 450ГБ — пугает: 450*15/60 = 112.5 часов. Однако на деле пока всё идёт получше: примерно 20% за 40 минут, 30% за один час. Т.е. предположительно процесс займет более трёх часов, а не 112. И действительно, процесс занял примерно 3 часа 40 минут, по мне так вполне адекватное время.

Теперь я ещё раз запустил изменение типа массива:
=> ctrl slot=0 ld 1 modify raid=1+0

На этот раз процесс пошёл:

logicaldrive 1 (838.3 GB, RAID 1+0, Transforming, 1% complete)


Процесс изменения типа массива идёт заметно дольше: если при добавлении диска 30% прошло за один час, то тут — примерно за полтора часа. 50% получили через 2 часа 40 минут. Окончания этого процесса я не дождался, посчитаем так: 50% за 2 часа 40 минут, будем считать, что 100% получилось за 5 часов 20 минут, это существенно больше времени на добавление одного диска (3 часа 40 минут).

На данном этапе у меня получилась следующая конфигурация:
=> ctrl slot=0 show config

logicaldrive 1 (838.3 GB, RAID 1+0, OK)

physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 450 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 450 GB, OK)
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 450 GB, OK)
physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 450 GB, OK)

unassigned

physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 450 GB, OK)
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 450 GB, OK)
physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 450 GB, OK)


Добавляю в массив ещё два диска:
=> ctrl slot=0 ld 1 add drives=2I:1:6,2I:1:7

Процесс пошёл достаточно быстро — 10% примерно за 15 минут, а 25% за 40 минут. Общее время составило примерно 3 часа 30 минут, т.е. примерно столько же, сколько ушло на добавление одного диска.

По окончанию процесса оказалось, что размер логического диска остался прежним, а в массиве появилось неиспользуемое пространство:
=> ctrl slot=0 show config

array A (SAS, Unused Space: 858429 MB)

logicaldrive 1 (838.3 GB, RAID 1+0, OK)

Чтобы расширить логический диск нужна ещё одна команда:
=> ctrl slot=0 ld 1 modify size=max
Вместо слова «max» в ключе «size» можно указать размер в МБ.
После ввода этой команды утилита выдёт предупреждение о том, что некоторые операционные системы не понимают такое расширение и данные могут стать недоступными:
Warning: Extension may not be supported on certain operating systems.
Performing extension on these operating systems can cause data to
become inaccessible. See HPSSA documentation for details. Continue?
(y/n)

Я сделал резервные копии, понадеялся на продвинутость CentOS 7 и согласился с предупреждением. Команда выполнилась быстро, система осталась в рабочем состоянии и размер логического диска увеличился:
=> ctrl slot=0 show config

array A (SAS, Unused Space: 0 MB)

logicaldrive 1 (1.2 TB, RAID 1+0, OK)


Оставшийся, нечётный, диск я решил настроить в качестве запасного (spare). Сделать это можно только после окончания процесса трансформации массива:
=> ctrl slot=0 ld 1 add spares=2I:1:8 sparetype=autoreplace
Эта процедура занимает немного времени — несколько секунд.

С типом запасного диска у меня остались некоторые сомнения, из документации я понял, что тип «Dedicated» означает, что после замены неисправного диска будет проведена перестройка массива с переносом данных с запасного диска на новый, а в случае типа «Auto-Replace» — запасной диск как бы насовсем заменит в массиве неисправный, а после замены новый диск станет запасным и перестройка массива не потребуется. Кроме того запасной диск типа «Dedicated» может быть использован для нескольких массивов, тогда как диск типа «Auto-Replace» нет. У меня массив один и перестройка массива мне не нужна, так что я выбрал тип «Auto-Replace».
Надеюсь я не ошибся в понимании документа, вот цитата:
— Dedicated — When the failed data drive is replaced, it must be rebuilt from the data on the spare drive. In Dedicated mode, one spare can be dedicated to multiple arrays.
— Auto-Replace Drives — The spare for the failed data drive automatically becomes the replacement data drive. When the spare is replaced, the data drive does not need to be rebuilt. In Auto-replace mode, spare drives cannot be shared between arrays.

Узнать тип запасного диска можно в выводе следующей команды (правда там много информации):
=> ctrl slot=0 show config detail

Array: A
Interface Type: SAS
Unused Space: 0 MB
Status: OK
MultiDomain Status: OK
Array Type: Data
Spare Type: autoreplace
HP SSD Smart Path: disable


Изменить тип запасного диска можно вот так:
=> ctrl slot=0 array A modify sparetype=dedicated


Всё это время я думал в каком виде дополнительное пространство будет доступно в системе. Наиболее логичным мне показался вариант, что просто появится свободное, нераспределённое, место на том же диске, которое я смогу использовать как обычно. И вот, сразу после окончания процесс трансформации, я вижу прежний размер диска:
parted --list
Model: HP LOGICAL VOLUME (scsi)
Disk /dev/sda: 900GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 525MB 524MB fat16 EFI System Partition boot
2 525MB 32.7GB 32.2GB xfs
3 32.7GB 49.9GB 17.2GB linux-swap(v1)
4 49.9GB 900GB 850GB xfs

Пришлось перезагрузить сервер. После этого видим, что диск стал нужного размера:
dmesg | grep sda
[ 2.314187] sd 0:0:0:0: [sda] 2637097072 512-byte logical blocks: (1.35 TB/1.22 TiB)

Однако при попытке посмотреть разделы на диске утилитой «parted» получаю сообщение о том, что конец диска не там где должен быть и не всё место доступно с предложением исправить ошибки, я согласился на исправление (ввёл fix) и увидел новый размер диска:
parted --list
Error: The backup GPT table is not at the end of the disk, as it should be.
This might mean that another operating system believes the disk is smaller.
Fix, by moving the backup to the end (and removing the old backup)?
Fix/Ignore/Cancel? fix
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 879032320
blocks) or continue with the current setting?
Fix/Ignore? fix
Model: HP LOGICAL VOLUME (scsi)
Disk /dev/sda: 1350GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 525MB 524MB fat16 EFI System Partition boot
2 525MB 32.7GB 32.2GB xfs
3 32.7GB 49.9GB 17.2GB linux-swap(v1)
4 49.9GB 900GB 850GB xfs

При помощи той же утилиты parted смотрю неиспользованное место на диске:
parted /dev/sda print free
Model: HP LOGICAL VOLUME (scsi)
Disk /dev/sda: 1350GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
17.4kB 1049kB 1031kB Free Space
1 1049kB 525MB 524MB fat16 EFI System Partition boot
2 525MB 32.7GB 32.2GB xfs
3 32.7GB 49.9GB 17.2GB linux-swap(v1)
4 49.9GB 900GB 850GB xfs
900GB 1350GB 450GB Free Space

Вижу свободное пространство. Теперь надо расширить нужный мне раздел номер 4. Поиск в Гугле привёл к двум вариантам: через утилиту «parted» командой «resize», но такой команды не оказалось, при помощи утилиты «xfs_growfs», но она менять размер отказалась без объяснения причин. Тогда я решил просто удалить раздел (он последний на диске) и создать его снова при помощи обычного «fdisk» — удалил, создал, сохранил изменения (сохраняем только в самом конце). После этого пришлось перезагрузиться снова.

После загрузки системы вижу, что размер раздела увеличился и свободного места на диске больше нет:
parted /dev/sda print free
Model: HP LOGICAL VOLUME (scsi)
Disk /dev/sda: 1350GB
Sector size (logical/physical): 512B/512B
Partition Table: gptDisk Flags:

Number Start End Size File system Name Flags
1 1049kB 525MB 524MB fat16 EFI System Partition boot
2 525MB 32.7GB 32.2GB xfs
3 32.7GB 49.9GB 17.2GB linux-swap(v1)
4 49.9GB 1350GB 1300GB xfs

Раздел в порядке, данные на месте. Наши победили почти без потерь (кроме времени), но, конечно, надо сначала сделать резервные копии )

Список литературы

Документация по управлению массивом: HPE Smart Storage Administrator. User Guide (Спасибо Максиму Брагину из компании «Logic» за ссылку).

CentOS 7: MariaDB

Настраиваем репозиторий — в папке /etc/yum.repos.d создаём файл mariadb.repo со следующим содержимым:
# MariaDB 10.1 CentOS repository list — created 2015-09-11 06:33 UTC
# mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

Это конфиг для моей версии. Можно сгенерировать этот конфиг прямо на сайте MariaDB — downloads.mariadb.org/mariadb/repositories/

Затем устанавливаем пакеты:
yum install MariaDB-server MariaDB-client

CentOS 7: Отключение FirewallD и возвращение iptables

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

Действия для включения iptables и отключения FirewallD:

yum install iptables-services
systemctl mask firewalld.service
systemctl enable iptables.service
systemctl enable ip6tables.service
systemctl stop firewalld.service
systemctl start iptables.service
systemctl start ip6tables.service

Linux иштетүү системасынын версиясын кароо

Linux иштетүү системасынын версиясын кароо дистрибутивге (Red Hat Linux, Ubuntu, Debian, CentOS жана башка) карай өзгөрүшү мүмкүн, бирок, көбүнчө ылдыйда берилген командалар колдонулат.

Linux иштетүү системасынын дистрибутивинин атын жана версиясын кароо үчүн:

$ lsb_release -a

LSB Version: :core-4.0-amd64:core-4.0-ia32:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-ia32:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-ia32:printing-4.0-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 5.11 (Tikanga)
Release: 5.11
Codename: Tikanga

Дистрибутивдин атын жана версиясын бул ыкма менен дагы караса болот:

$ cat /etc/issue

Red Hat Enterprise Linux Server release 5.11 (Tikanga)

Linux иштетүү системасынын өзөгүнүн версиясын кароо үчүн:

$ uname -a

Linux srvname 2.6.18-398.el5 #1 SMP Tue Aug 12 06:26:17 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux

Бул жерде Linux иштетүү системасынын «бит»тиги тууралуу дагы маалымат бар: x86_64 — 64-биттик иштетүү системасына таандык экенин билдирет.