У SAP Basis администратора очень ответственная работа. Любая ошибка может привести к простою системы, от которой зависит работа всей компании. Поэтому для системного администратора должна стать заповедью известная поговорка "семь раз отмерь, один отрежь". И в данном случае под "семь раз отмерь" надо понимать следующее:
- чтение всей документации, к которой вы можете получить доступ;
- проведение тестовых прогонов планируемых шагов на учебной или тестовой системе;
- и обязательно предварительно сделанная резервная копия системы.
Таким образом у системного администратора обязательно должна быть система, на которой всегда можно потренироваться. При этом её архитектура должна быть максимально приближена к архитектуре продуктивной системы. Как
на кошках. :)
При старте каждого более или менее крупного проекта идеальным вариантом будет создание полностью независимой от основного ландшафта тестовой системы. В этом случае на данной системе можно будет несколько раз провести планируемые шаги. Отработать как их точность и необходимость, так и оптимизировать время выполнения, минимизировав будущий downtime продуктивной системы. Благодаря независимости в любой момент можно инициировать систему заново, сбросив её к начальному состоянию. При этом не затрагивается работа как пользователей, так и коллег по разработке и тестированию их собственных задач.
Ну а на ещё более низком уровне, хорошо бы иметь маленькую учебную систему. На которой администратор может проводить свои эксперименты, изучать новые версии или методы работы.
И я не исключение, всегда старался держать свой маленький сервер для таких задач. Я про него как-то уже упоминал, например, в
этом посте. На текущий момент это такой же самостоятельно собранный компьютер на базе процессора Intel Core i7 7700 (4 ядра/8 потоков). На борту 64 Гб оперативной памяти. Операционная система установлена на небольшой SSD, а в качестве хранилища 2 диска по 4 Тб, объединённые в программный
RAID0. Отказоустойчивость на такой машине не требуется, а такое решение небольшой прирост в скорости, пусть и в редких задачах, но даёт. Плюс установлено ещё несколько жёстких дисков меньшего объёма, куда я периодически делаю бэкап данных с основного хранилища.
На этом сервере у меня работает последняя
IDES система для функциональных консультантов, системы моих
обучающих пакетов, различные
Trial системы, маленькие виртуальные машины, где я тестирую клиентские приложения и так далее. Виртуальных машин много, но одновременно работают не все.
До прошлой недели на сервере стояла операционная система openSUSE 42.3, которая отлично и безотказно работала несколько лет. Хотя поддержка этой операционной системы закончилась в 2019 году, процесс обновления всё откладывался. И вот, на прошлой неделе я наконец решился на апгрейд. Ну чтобы идти в ногу со временем. :) Процедура оказалась на удивление простой. Вот основные шаги:
1. Создать резервную копию операционной системы и всех данных.
2. Открыть терминал под пользователем root.
3. Удостовериться, что достаточно места в корневой файловой системе. В моём случае понадобилось 2-3 Гб. Свободное пространство можно посмотреть командой:
# df -h
3. Обновить текущие репозитории и текущую версию системы командами:
# zypper ref
# zypper up
4. Просмотреть список подключенных репозиториев на предмет нестандартных командой:
# zypper lr --url
5. Можно перед обновлением удалить ненужные в будущем пакеты. Это ускорит процесс апгрейда. Команда удаления:
# zypper rr package_name
6. Скопировать старые репозитории (для резервной копии) командой вида:
# cp -Rv /etc/zypp/repos.d /etc/zypp/repos.d.42.3
7. Сконвертировать имена репозиториев для нового релиза. Для этого достаточно просто переименовать версии в строках командой:
# sed -i 's/42.3/15.0/g' /etc/zypp/repos.d/*
Проверить переименование хранилищ пакетов можно командой вида:
# zypper lr --uri
8. Импортировать ключи и обновить локальный кэш репозиториев командой:
# zypper --gpg-auto-import-keys ref
9. Следующая команда выполнит обновление, предварительно скачав нужные пакеты:
# zypper dup --download-in-advance
10. После окончания процедуры перезагрузить компьютер.
По такой процедуре я сделал обновление в 2 шага: openSUSE 42.3 -> openSUSE 15.0, а потом openSUSE 15.0 -> openSUSE 15.2 (рис. 1-3). Никакого особого смысла в этом не было, можно было сделать и в один шаг, но мне так захотелось. Обе процедуры прошли без ошибок и довольно быстро (25-30 минут каждый этап). Вся функциональность продолжила работать.
 |
| Рис. 1. Состояние системы до обновления. |
 |
| Рис. 2. Состояние системы после обновления до openSUSE 15.0. |
 |
| Рис. 3. Состояние системы после обновления до openSUSE 15.2. |
Помощь и описание процедуры нашёл на странице
этого блога. Официальная страница апгрейда
здесь.
Так же ещё стоит отметить, что на текущий момент дистрибутивы openSUSE и SLES построены на максимально схожей базе пакетов. Поэтому процедура перехода открытого openSUSE в какой-то из корпоративных SLE-дистрибутивов проще, чем описанный апгрейд. Выполняем
эти шаги и наблюдаем как лёгким движением руки брюки превращаются... в
элегантные шорты ©. :)
Желаю всем лёгких апгрейдов. :)
