В помощь системному администратору: MTPuTTY

На обучении по VMware, которое я проходил в конце мая, открыл для себя новую программу.  Наверное, многие из вас знают и пользуются программой для доступа к Unix операционным системам - Putty? Это небольшая, компактная программа позволяет открывать терминалы по протоколам SSH и Telnet и выполнять административные задачи на серверах. Я упоминал о ней в своём посте "Программное обеспечение для администратора". Программа имеет аскетичный интерфейс: у программы одно основное окно, где можно выполнять настройки и вести список сохранённых сессий. Терминалы открываются в отдельных окнах (рис. 1). 

Рис. 1. Основное окно программы Putty и открытый терминал.

Сохранённые сессии никак не организуются, хранятся в едином списке. Если хотите их сохранить и/или перенести на другой компьютер, то найти их можно в системном реестре Windows (рис. 2).

Рис. 2. Ветка системного реестра с сохранёнными сессиями Putty.

Программа, о которой я упоминал в начале поста - это MTPuTTY. Устанавливаются совместно с Putty и представляет собой надстройку над ней. То есть для работы терминалов используется стандартная, проверенная Putty. А данная утилита позволяет открывать все сессии во вкладках одного окна. Дополнительно возможна организация списка сохранённых сессий в древовидной структуре. Плюс есть возможность отправки скрипта (списка из команд) нескольким открытым сессиям. Утилита поддерживает сохранённые сессии из оригинального Putty, но переносить их в список этой программы и редактировать нельзя (рис. 3 - 1). Списки же самой MTPuTTY могут быть организованы гораздо удобнее (рис. 3 - 2).

Рис. 3. Основное окно программы MTPuTTY.

Второе отличие списков - хранит их программа не в системном реестре, а в xml-файле. Плюс есть функциональность для экспорта и импорта дерева сохранённых сессий во внешний xml-файл. 

Сайт программы, откуда её можно скачать - тут. Так же там есть небольшая онлайн-справка в виде FAQ. 

Мне программа понравилась, добавил её к своим инструментам администратора.

У кого есть свои открытия в плане программ-утилит в помощь системным администраторам, прошу делиться в комментариях.

Автор: Шиболов Вячеслав Анатольевич

История одной миграции SAP системы или Век живи, век учись! - III

Данный пост продолжает серию кратких записей о моих открытиях в мире SAP систем и около них. Согласно первой части пословицы: "Век живи, век учись..." такие открытия периодически случаются и в тех областях, где казалось бы всё изучено вдоль и поперёк. 

Сегодня рассказ будет не очень кратким. Дело в том, что вторую половину прошлого года я занимался большим проектом по миграции ландшафта из систем SAP на новую платформу и хочу об этом рассказать. Я долго думал, как назвать этот пост. Но, в итоге, всё таки решил отнести его к этой серии. Почему я так поступил, вы поймёте по ходу рассказа. :)

Исходная ситуация - мрак

У заказчика старенькие системы SAP R/3 4.6C работали на уже давно морально устаревшем оборудовании. Когда-то очень хорошее оборудование HP на платформе PA-RISC давно выработало свой ресурс и требовало замены. Ситуация осложнялась тем, что компания HP прекратила разработку и поставку серверов не только на платформе PA-RISC, но и даже на когда-то перспективных процессорах Itanium (всю печальную историю этого процессора можно прочитать тут). Используя сервера на платформе Itanium можно было бы остаться в рамках операционной системы HP-UX и почти бинарной совместимости со старыми серверами. Но поезд ушёл, оборудование полностью морально и физически устарело и ситуация была катастрофическая. SAP системы, как вы поняли, работали на платформе с операционной системой HP-UX, а в качестве базы данных использовалась Oracle 8i. Поддержки со стороны ни одного из производителей программного обеспечения таких старых версий, как вы догадываетесь, тоже уже не было. 

Свет в конце туннеля 

Апгрейд версии SAP системы в рамках данного проекта не планировался. Поэтому анализ Product Availability Matrix для текущей версии системы показал, что, если выбрать платформу x86_64, на которую сейчас переходит большинство вендоров серверного оборудования, то перенос на неё  системы возможен. Правда придётся в качестве целевой операционной системы использовать SUSE Linux Enterprise Server версии 11 с последним SP4, а базу данных обновить до Oracle 10g. Ну и ядро SAP системы необходимо подтянуть до максимального уровня - 46D_EX2 (рис. 1).

Рис. 1. Матрица совместимости для исходной версии системы.

Подготовка - тяжело в учении...

"Тяжело в учении, легко в бою" говорил А.В. Суворов. В проекте миграции так же: самое главное подготовка и тестовая миграция. Чем больше итераций миграции с максимально приближёнными к боевым условиями удастся провести перед самой процедурой, тем легче и чётче пройдёт сам процесс переезда на новое оборудование. 

В связи с тем, что в данном случае планировалось полностью изменить платформу, было принято решение проводить процедуру миграции по схеме Heterogeneous System Copy.
Напомню, что процедура состоит из 3 крупных этапов:

1. EXPORT - выгрузка базы данных исходной системы в файлы универсального экспортного формата SAP.
2. MOVE - перенос экспортных файлов на новый сервер.
3. IMPORT - установка новой версии системы с последующим импортом данных из полученных экспортных файлов.

Сначала я разбирался с экспортом. Оборудование, как я уже говорил, морально устарело, производительность для текущей системы была очень низкая. Но стоит отметить - было и 2 положительных момента:
- относительно небольшой объём базы данных - 2,4 Тб;
- хорошая производительность дискового массива (HP EVA8400).

При экспорте базы данных SAP системы строго рекомендуется останавливать сервер приложений, не останавливая при этом СУБД. Экспериментов в данном случае требовалось много, а тестовой среды у заказчика на момент старта этого проекта не было. Поэтому приходилось всё делать на продуктивной системе. С одной стороны это большой плюс: я проводил тестовые выгрузки на реальном сервере, который будет участвовать в финальной выгрузке. С другой стороны, останавливать продуктивную систему постоянно никто не даст.
В процессе работы в голову пришло решение - делать выгрузки на работающей системе. В выходные дни у заказчика нагрузка со стороны пользователей минимальна, поэтому я по-тихому проводил тестовые выгрузки, нащупывая оптимальные параметры Oracle и количество параллельных потоков. А проблемы возникали. Например, когда при использовании ряда рекомендуемых в SAP notes параметрах Oracle, выгрузка некоторых таблиц зависала, как будто происходили какие-то блокировки на уровне базы данных. Поэтому оптимальные параметры пришлось нащупывать экспериментально. Выгрузки при работающей системе получались не 100% консистентными, но цель была не в этом. За подготовительный период удалось провести 2 или 3 продуктивные выгрузки с остановом сервера приложений SAP и полной загрузкой существующего оборудования.

В итоге, я добился отлаженного процесса экспорта базы данных, который занимал в общей сложности 21 час. Процесс шёл в 7 потоков при 8 процессорных ядрах. Больше потоков запускать не было смысла. Дело в том, что используя старые версии утилит выгрузки можно полу-скриптовыми методами выделить крупные таблицы в отдельные потоки. Но утилиты не позволяют разбивать таблицы на части при выгрузке, как, например, более свежие версии инсталляторов SAP. Ну вы догадались, что выгрузка пары самых крупных таблиц как раз и длилась эти самые 21 час. Дисковый массив был загружен в среднем на 65%, а потоки упирались в производительность по процессорам.

Экспортные файлы заняли около 500 Гб. Это 1/5 от объёма исходной базы данных. При экспорте данных используется сжатие и стоит учесть тот факт, что при этой процедуре не происходит выгрузки табличных пространств PSAPTEMP и PSAPROLL/PSAPUNDO, а также индексов. Индексы генерируются заново на этапе IMPORT. Поэтому объём файлов в экспорте меньше объёма исходной базы данных.

С этапом переноса файлов больших проблем не было. SAP не рекомендует использовать для переноса файлов по сети NFS, поэтому была отработана процедура переноса по протоколу FTP. Старые сервера имели на борту сетевые адаптеры на 1 Гбит/сек, поэтому перенос на новое оборудование 500 Гб требовал 2,5 часа времени. При копировании использовалась утилита wget, которая позволяет одной командой легко инициировать копирование структуры директорий с файлами. Информацию про неё нашёл тут.

Дополнительные затраты по времени занял процесс проверки контрольных сумм (CRC) файлов после переноса. На исходном сервере процесс сбора контрольных сумм утилитой cksum, работая в один поток, занимал 2 часа. Благо этот процесс можно было совместить с этапом самого копирования файлов по сети. А на новом оборудовании утилита cksum отрабатывала за 30 минут. Для сравнения файлов с контрольными суммами использовалась утилита diff. В итоге, расчётное время для данного этапа составило - 3 - 3,5 часа. 

Для тестирования третьего шага миграции (IMPORT) компанией HP был предоставлен во временное пользование сервер с целевой архитектурой. Это был сервер начального уровня HPE ProLiant DL380 Gen10 с процессорами Intel Xeon Gold 6136 и внутренним RAID контроллером, где 12 SAS дисков, объединённые в RAID уровня 6, образовывали единое дисковое пространство. И до поставки и настройки основного аппаратного комплекса я использовал данный сервер.

Разговор про процесс установки очень старой системы SAP R/3 4.6C на относительно современную платформу из SLES 11 и Oracle 10g я даже начинать не буду. Установочные файлы и сам процесс пришлось буквально собирать по крупицам из десятков SAP notes и других источников. Версия системы старая, вряд ли кому-то сейчас это будет интересно.

Поэтому сразу перейду к одному из самых затратных по времени процессов установки системы - импорту данных в новую копию системы. Напоминаю ещё раз: версии системы SAP и всех утилит установки очень старые. Гибкости совершенно никакой. Скрипты берут экспортные файлы с данными исходной базы и загружают их в новую базу. Если при экспорте последовательность файлов легко прослеживалась - файлы (потоки) шли по алфавитному порядку. То при процессе импорта утилита не использовала порядок ни по алфавиту, ни по времени создания файлов. Последовательность при этом была, причём для каждого сервера своя! То есть утилита для каждого сервера определяла свой порядок и уже не меняла его при повторных попытках установки и импорта целевой системы. Но от чего зависит этот порядок для конкретного сервера мне понять так и не удалось! Поэтому повозившись пару недель с этим моментом, я смирился.
При импорте также можно поиграться с параметрами Oracle, выставив их в оптимальные значения для загрузки данных и массовой генерации индексов. 

Аналогичным образом утилиты позволяют поиграться с параллелизмом. Современные процессоры семейства Intel Xeon имеют много физических и логических ядер, поэтому даже при ограничении количества процессорных сокетов в одном сервере дают хорошее общее количество процессорных ядер. В общем, не буду долго ходить вокруг да около, результаты моих экспериментов на тестовом сервере приведены в таблице (рис. 2).

Рис. 2. Затраты времени на этап IMPORT на тестовом сервере DL380.

Помимо разного количества потоков прогоны отличались еще последовательностью загружаемых таблиц (процесс не контролируемый, как я писал выше) и параметрами Oracle. По процессорам ресурсов было достаточно, но всё упиралось в дисковую подсистему. Я пробовал и больше потоков (16), но процесс только растягивался во времени. Задержки (latency) на дисковом массиве подсказывали, что больше выдавать он не может. Я смирился с данными временными параметрами для этого этапа. Была надежда (даже уверенность) что дисковый массив продуктивного комплекса уровня Enterprise, да ещё и полностью на SSD дисках, даст процессу импорта развернуться и покажет сокращение временных затрат. 

И вот настал тот день, когда целевой аппаратный комплекс был инсталлирован, настроен и передан в мои руки. Ну сейчас я развернусь, подумал я. :)

Знаете сколько импортировались данные на сервере, расположенном на новом комплексе? С учётом больших объёмов физической памяти и щедро настроенных буферов Oracle. С учётом дискового массива HPE 3PAR StoreServ 8440 полностью на SSD дисках. С учётом RAID 1 массива, собранного для максимального быстродействия не только по чтению, но и по записи. 12 потоков импорта данных и итоговое время 38 часов! Сказать, что я был разочарован, ошарашен или взволнован, это совсем никак не выразить гамму моих чувств. Я не был совершенно похож на довольных инженеров со страницы с описанием дискового массива. Я был просто раздавлен этими цифрами. Время на тестирование процесса еще оставалось, поэтому я перепроверил цифры, перезапустив процесс копирования системы ещё пару раз. Результат с учётом погрешности был примерно один и тот же. Даже 16 потоков дали 33,5 часа общего времени на этап IMPORT.

К задаче были подключены инженеры HP, отвечающие за подготовку железа, дискового массива и оптической сети. Было перечитаны ещё раз все Best Practics. Переведены виртуальные диски, созданные на 3PAR, с "тонких" на "толстые". Включена балансировка на всех уровнях оптической сети и коммутаторов, перепроверены параметры на всех уровнях системы. Но результат был всё тот же. 

Инженеры по оборудованию даже организовали мне показательное выступление с синтетическими тестами максимальной скорости по Мб/сек и IOPS, которые может максимально выдавать дисковый массив при сохранении низких значений latency и Service Time со стороны 3PAR. Таким образом, доказав мне, что на уровне оборудования всё прекрасно. Но почему процесс импорта не укладывался в меньший интервал? Процессорных ресурсов достаточно. Дисковый массив явно одной левой отрабатывает запросы от систем. Кто же тогда виноват?

Немало часов и дней я провёл в размышлениях и экспериментах. И неожиданно нащупал "узкое место". Если вы спросите меня "Как?", то могу только предположить. Однажды, отчаявшись, я просматривал журнал Oracle и увидел ошибку "Chekpoint not complete", в которой, в принципе, нет чего-то удивительного при массовых операциях загрузки в базу данных. Но это меня зацепило. Нашёл и перечитал SAP note 79341 - Checkpoint not complete. Одна из причин в журнальных файлах, говорилось в ней. Я вспомнил, что что-то про это было в, много раз перечитанной вдоль и поперёк, SAP note 806554 - FAQ: I/O-intensive database operations. Потом посмотрел SAP note 936441 - Oracle settings for R3load based system copy. И начал эксперименты. Результаты вы можете видеть в таблице (рис. 3).

Рис. 3. Затраты времени на этап IMPORT на целевом оборудовании.

Вы уже догадались, что проблема была в журнальных файлах (Redo Logs)! Инсталлятор  R3SETUP для системы SAP R/3 4.6C был спроектирован для установки системы на базу данных Oracle версии 8i. При установке системы автоматически создаются журнальные файлы в 4 группах, в каждой по 2 копии, размером 20 Мб! Для пустой начальной базы системы SAP R/3 в 20 Гб это нормальный размер. Но для загрузки продуктивных данных, накопленных за много лет (2 Тб), этого размера явно недостаточно. В SAP notes упоминали, что надо бы отключить зеркалирование журналов, оставив только одну копию в группе. Но я решил, что заодно, можно сразу поиграться и с размером. Всё равно его после разворачивания системы надо было увеличивать. Сконфигурировал останов скрипта установки системы R3SETUP и пересоздал группы журналов с одной копией нужного мне размера. Результатом стал взрывной рост скорости загрузки и уменьшение итогового времени. Изначально, понадеявшись, на производительность оборудования, я не подумал, что частое переключение между маленькими файлами журналов будет тормозить весь процесс. Век живи, век учись! В результате дальнейших экспериментов остановился на журналах по 1024 Мб (без копии) и 12 потоках. При этом процесс импорта ощутимо сильнее нагрузил процессоры и дисковую подсистему. А то до этого момента складывалась парадоксальная ситуация: ресурсов много, а процесс импорта их не использует.

Любопытства ради, я увеличил размер журналов и прогнал импорт и на тестовом сервере DL380. Выжал в итоге всё из внутреннего дискового массива, получив 12,5 часов итогового времени! 

Процесс переезда - легко в бою

Ну а сам процесс переезда прошёл легко и скучно. :) Перед последним прыжком был создан финальный план, куда я включил все полученные временные интервалы с запасом 15-20%. Были выделены выходные. И за два дня, в спокойном режиме, уложившись во все предыдущие измерения, был выполнен перенос системы на новое оборудование.
Итоговое время получилось: 21 + 3 + 6 = 30 часов. Плюс время на донастройку системы, подключение дополнительных инстанций SAP, тестирование.
Начальная цель выполнить переезд за выходные была достигнута.

А у меня от этого проекта осталась борода и стало может быть чуть-чуть побольше опыта. :)

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

Век живи, век учись!

Предыдущие выпуски:

• Век живи, век учись! - I
• Век живи, век учись! - II

Автор: Шиболов Вячеслав Анатольевич

Опрос: опыт работы с SAP системами

Первое программное решение на русском языке компания SAP выпустила в 1991 году. Это была SAP R/2 - система рассчитанная на работу на Мейнфреймах. Не думаю, что кто-то в России успел внедрить эту версию системы. 😊
В 1992 году выходит первая версия системы SAP R/3, а в Москве открывается подразделение компании SAP CIS. Таким образом, история SAP в СНГ насчитывает уже 27 лет.

Соответственно, количество специалистов с большим опытом работы в сфере внедрения и поддержки программных решений SAP увеличивается и увеличивается. Как говорят: опыт приходит с опытом. 😊

Конечно, не все занимаются всю свою жизнь только SAP, кто-то уходит в другие области. Но кто-то воюет дальше, считая, что нашёл своё место в жизни. Например, я занимаюсь этим уже 16 лет. Страшно даже подумать сколько это. 😲

В 2017 году я в своём блоге проводил опрос, целью которого было определить опыт администрирования SAP систем среди читателей моего блога. 

Проведём опрос еще раз и пересчитаемся? 😊 Я подозреваю, что на мой блог натыкаются не только те, кто администрирует SAP системы, поэтому опрос более общий - опыт работы с SAP системами. А во втором опросе отнесите себя к той или иной категории специалистов. Объединить два опроса в один у меня на используемом сервисе не получилось. Так что придётся ответить дважды.

Всем спасибо за ответы. Пора подводить итоги.

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

Рис. 1. Результаты опроса "Какой у вас опыт работы с SAP системами".

Рис. 2. Результаты опроса "В какой области SAP вы работаете".

Рис. 3. География участников по странам. 

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

Спасибо, что читаете мой блог. Смело давайте обратную связь - пишите комментарии к статьям, делитесь своим опытом, мыслями. Мне тоже важно знать, что мои статьи не уходят в никуда, а находят своего читателя. Если же есть личные советы, комментарии, критика, то пишите на электронную почту - shibolov@gmail.com.

Автор: Шиболов Вячеслав Анатольевич

Опрос: Web-браузер

Предыдущий опрос завершился полной победой Unix (Linux). Результаты на основе мнения 44 администраторов можно посмотреть тут.

Давайте теперь посмотрим на Web-браузеры.

Прошли те времена, когда почти единственным корректно работающим (то есть де-факто стандартом для тестирования у разработчиков сайтов) браузером был MS IE. Сейчас можно услышать опасения, что таким может стать Google Chrome. Да, и продукты компании SAP поддерживают большинство основных Web-браузеров примерно на одном уровне.

Давайте проведем опрос: какой Web-браузер вы используете на компьютере в качестве основного. В каком браузере у вас открыто большинство вкладок. Отметьте только тот, который у вас работает в большинстве случаев. В комментариях можно больше подробностей.
Спасибо за участие. Результаты, как обычно, в середине следующего месяца.

Опрос закрыт. Всего проголосовало 43 человека. Результаты голосования печальны для браузера Internet Explorer. Действительно, его времена прошли. Ни одного голоса. :) Первенство разделили Google Chrome и Mozilla Firefox (рис. 1).

Рис. 1. Результаты опроса.

Отвечающие по странам распределены как обычно (рис. 2).

Рис. 2. Географическое распределение респондентов.

Я лично использую в качестве основного Google Chrome, а MS Internet Explorer у меня на подхвате. Для проверки упрямых страничек и сайтов. Всё хочу вернуться обратно на Firefox, но последняя попытка была неудачной. Сейчас Mozilla, как раз, сделала крупное обновление. Хочу попробовать дать ему еще один шанс. :)

Автор: Шиболов Вячеслав Анатольевич

Опрос: Windows vs Unix

Предыдущий опрос про опыт администрирования SAP систем завершён. Результаты и обсуждение тут.

Предлагаю новый опрос. Представьте, что необходимо установить продуктивную SAP систему. Согласно PAM возможна установка на операционные системы семейства MS Windows и Unix-подобные (Linux, AIX, HP-UX и т.п.). Никаких особых ограничений ни в одной, ни в другой операционных системах со стороны SAP нет.
Что вы выберете для продуктивной системы? Ваше личное мнение. Анонимно. :)

Опрос завершён. В опросе приняло участие 44 человека. Всем спасибо за участие.

Итоги получились ожидаемыми: с большим отрывом победили Unix системы (рис. 1).

Рис. 1. Результаты опроса.

Моё личное мнение совпадает с мнением большинства. Я бы тоже выбрал Unix-подобную операционную систему. По объективным и субъективным причинам. Люблю я их. :)

Хотя чаще надо выбирать головой. Например, учитывать при выборе факт наличия навыков и опыта работа с операционной системой у администраторов и политики компании.

В пользу Linux стоить отметить тот факт, что база данных SAP HANA, которую компания разрабатывает уже 5 лет, работает только на Linux. На Windows они её так и не портировали.

Распределение участников опроса по странам, если кому интересно, можно найти на рис. 2.

Рис. 2. Участники опроса по странам.

Автор: Шиболов Вячеслав Анатольевич

Опрос: опыт администрирования SAP систем

Помню в 2004 году, когда я только начинал свой карьерный путь, проработав около двух лет, увидеть в живую консультанта с опытом 6 лет или более было большой редкостью и удачей. Мне тогда они казались зубрами, недосягаемой вершиной. :)

И это было не лишено смысла. Эти люди, на тот момент, были фактически теми, кто стоял у истоков внедрений SAP систем в России. Кто первым окунулся в романтику первых робких внедрений в России. Кто был ветераном на линии немецко-российских отношений между бизнесом и информационными системами для автоматизации этого самого бизнеса.

По прошествии лет пяти ситуация кардинально изменилась: специалистов на рынке труда в России стало больше, людей с большим опытом тоже. И шестью годами опыта в SAP-консалтинге или поддержке никого не удивишь. Сейчас тем более.

В 2011 году я в своём блоге проводил опрос, целью которого было определить опыт администрирования SAP систем среди читателей моего блога. К сожалению, на тот момент я использовал в качестве платформы для опросов средства blogspot.com и результаты опроса пропали. А я их не зафиксировал.

Поэтому давайте проведем опрос еще раз. Буду очень признателен, если Вы примете участие.

Опрос завершен, 39 человек приняли участие. Всем большое спасибо. Результаты получились следующие (рис. 1).

Рис. 1. Результаты опроса.

Распределение участников по странам на рис. 2.

Рис. 2. Распределение участников по странам.

Выводы очень грустные. У почти половины участвовавших огромный опыт администрирования SAP систем - больше 6 лет, а на мой призыв поучаствовать в наполнении блога никто не откликнулся. Неужели у вас нет каких-то заметок, идей для написания, пусть небольшого, но кому-то полезного поста? Не верю. В чём причина? Лень, отсутствие времени, нежелание делиться своими знаниями или не нравится предложенный формат? Напишите хотя бы почему нет. :) Если вы начинали вести свой блог и у вас было несколько постов, то можно, актуализировав, прислать их. Дополнительный ресурс не будет лишним. Мои статьи тоже дублируются: на этом блоге и на портале SAPLand.

Написание статей это прекрасная возможность. Недавно SAPLand расширил набор бонусов для авторов статей на портале:

1. Книги на русском языке о SAP (нашего издательства) и электронные на английском языке (авторам нескольких статей) в подарок. 
2. Журнал SAP Professional Journal Россия в бумажной форме по почте бесплатно.
3. После одной статьи (в год) предоставляется бесплатный доступ к платной базе знаний переводных материалов https://goo.gl/KBUPrr.
4. По запросу высылаются отдельные статьи из базы http://sapexperts.wispubs.com.
5. Предоставляется возможность бесплатно обучаться на мастер-классах, проводимых порталом (авторам нескольких статей). Очередная сессия состоится с 23 по 27 октября 2017 года.

Так что не теряйтесь. :)

Предыдущий опрос можно найти в посте "Опрос: версия SAP ERP".


Автор: Шиболов Вячеслав Анатольевич

Поиск авторов для написания постов

Я веду этот блог с переменным успехом уже 9 лет. Были периоды, когда по несколько месяцев я ничего не публиковал, но в целом, я считаю, что ресурс держится на своём уровне.

Мою историю того, как я попал в SAP и занялся администрированием SAP систем, вы знаете. Об этом я писал в посте "35 лет или как я попал в SAP". Также я писал о том, что мне приносит написание статей в этом блоге ("Зачем я веду этот блог?").

Читая эти две истории, которые я описал в предыдущих постах, можно вспомнить фразу "время разбрасывать камни и время их собирать". Что означает, что в карьере любого человека есть время, когда он интенсивно впитывает знания, учится и постигает тонкости мастерства. А есть время, когда он сам отдаёт свои знания и делится опытом. Может быть, так и работает глобальный механизм человеческого развития и движения вперед. Причём, передача знаний это сам по себе процесс обучения, но уже на более высоком уровне.

Я предполагаю, что большинство тех, кто читает этот блог занимается администрированием SAP систем, как и я, или работают в смежных областях. И я на 100 % уверен, что хотя сфера занятий у нас одна, у каждого из нас свой путь, который нас привёл в эту профессию. И свой уникальный опыт. Все проекты разные. У компании SAP огромное количество решений и систем, которые в большинстве своём базируются на одной платформе (SAP Basis или SAP NetWeaver), но нюансы у которых разные. Комбинаций систем (особенно, если учитывать версии продуктов), используемых на предприятиях, огромное количество. Даже в рамках одной системы - SAP ERP, на данный момент эксплуатируется огромное количество версий, что показывают результаты недавнего опроса. Задачи, решаемые в рамках проектов, формируют картину вашего неповторимого и уникального опыта.

К чему я это всё веду? Одна голова хорошо, а две лучше. Предлагаю вам поделиться своим опытом и своими знаниями и стать соавторами данного ресурса.

Стоит отметить, что среди почти 300 постов этого блога есть парочка не моих. Это пост "История одного долгоиграющего отчета" от Дмитрия Бондарева и "Что такое SAP?" от Алексея Петрова. Первый был опубликован по инициативе автора, а второй по моей. Но это были единичные случаи. Сейчас же я предлагаю стать постоянными соавторами блога "Записки SAP Basis консультанта". Как я уже упоминал в одном из постов, многие начинают свои блоги, но не многим хватает упорства и вдохновения постоянно их поддерживать. Я же предлагаю соединить наши усилия и создать ресурс, который объединит опыт и знания многих в одной базе знаний по администрированию SAP систем.

Итак, что я предлагаю:

• ресурс с целевой аудиторией из SAP Basis специалистов в количестве примерно 90-100 читателей в день;
• помощь с моей стороны в оформлении и написании постов и статей (соавторство);
• возможность структурировать свои знания, оформив их в читаемый вид;
• признание сообщества, широкая известность в узких кругах;
• страница автора с резюме на сайте этого блога (аналог моей) при публикации хотя бы 3-х статей,
• в случае публикации успешной статьи, возможность выхода на аудиторию SAPLand.ru.

Тему для статьи вы можете выбрать сами: всё что связано с администрированием SAP систем, операционных систем и баз данных, вопросы интеграции, автоматизации задач администратора и так далее. Примерную карту областей знаний SAP Basis администратора можно найти в моей попытке её составления тут.

Все свои темы, предложения и статьи присылайте мне на электронный ящик - shibolov@gmail.com.

Статьи публикую на ресурсе я с обязательной ссылкой на авторство. Я помогаю оформлять статьи, внося корректировки с согласия автора. Даты публикации выбираю я.

Признательность сообщества SAP Basis администраторов и удовлетворение от хорошего дела гарантирую. :)

Автор: Шиболов Вячеслав Анатольевич

Маленькие эксперименты. Fake RAID

RAID массив это технология виртуализации данных, которая объединяет несколько дисков в логический элемент для избыточности и повышения производительности. В русской версии Википедии есть прекрасная статья про виды массивов. Поэтому повторяться здесь не буду. Остановлюсь лишь на том, что RAID массивы строятся с помощью RAID контроллеров, которые бывают трех видов:

• аппаратный RAID контроллер,
• программный RAID контроллер,
• аппаратно-программный RAID контроллер.

Первый наиболее привлекателен по отказоустойчивости и производительности. Отличный выбор для использования в промышленном серверном оборудовании. Второй представляет собой скорее возможности операционной системы (или дополнительного ПО), когда при работе существенно нагружается основной процессор системы.

Третий вид - это чип, чаще всего, интегрированный в современные материнские платы для стационарных компьютеров, выполняющий часть работы на аппаратном уровне, а часть с помощью ресурсов основного процессора (необходима установка драйверов для ОС).

Как я уже упоминал в этом посте, у меня есть небольшой сервер для экспериментов и обучения. Сервер собран на базе 6-ти ядерного процессора AMD Phenom II X6 1055T, которому до сих пор нет адекватной по цене замены. :) В качестве материнской платы для моей системы была установлена модель ASUS M4A77T, которая имела на своем борту встроенный аппаратно-программный RAID контроллер. На тот момент у меня было 3 диска по 750 Гб, которые, ради эксперимента, я пробовал объединять в RAID массив. Ничего хорошего у меня тогда не вышло. Массив после 2-3-х недель работы сбоил, 'разваливался' и терял данные. И в таких видах RAID массивов (аппаратно-программный) я на тот момент разочаровался. После я даже узнал, что такие контроллеры называют fake RAID, что, согласитесь, не очень лестно. :)

В этом году я заменил материнскую плату на новую модель - ASUS M5A97 R2.0, оставив процессор и память из старой конфигурации. Новая материнская плата - новые эксперименты. :) На этот раз я работал с двумя дисками объемом 1 Тб каждый (модель WD Caviar Blue 7200 rpm 64 Mb).

Стоит отметить, что на данный момент, наибольшее распространение получили 3 уровня RAID:

• RAID 0 или striping - дисковый массив повышенной производительности, использующий для хранение данных чередование блоков данных (stripe), без отказоустойчивости, но чем больше дисков, тем больше производительность.
• RAID 1 или зеркало (mirroring) - массив из двух (или более) дисков, являющихся полными копиями друг друга. Обладает высокой отказоусточивостью, но низким коэффициентом использования дискового пространства.
• RAID 5 - дисковый массив с чередованием и «не выделенным диском чётности». Обладает самой низкой производительностью из данных трех, но оптимально использует дисковое пространство при хорошем уровне отказоустойчивости. Отлично подходит для хранения больших объемов данных - "дешево и сердито".

У меня стояла задача прежде всего получить ускорение при использовании обычных SATA3 дисков. Выбор пал в пользу RAID 0. Результаты тестов отображены на рисунках 1, 2 и 3.

Рис. 1. Тест чтения одиночного диска и RAID 0 массива.

Рис. 2. Тест записи одиночного диска и RAID 0 массива.

Рис. 3. Тест чтения/записи одиночного диска и RAID 0 массива.

На всех снимках экранов слева результаты теста одиночного диска, справа - RAID 0 массива на двух дисках. Операционная система на сервере - MS Windows 2008 Server.

Как видно из тестов, прирост производительности есть (гарантировано 60-70 %), и при чтении, и при записи. Стабильность работы контроллера - средняя. Ошибок, сбоев пока не было. 

Плюсы:

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

Минус один, но существенный:

• низкая отказоустойчивость.

Во-первых, вероятность выхода из строя диска в массиве увеличивается в 2 раза, чем в случае использования одного диска. Во-вторых, привязка данного вида RAID массива к контроллеру (как и в случае аппаратного RAID контроллера), в данном случае, ко всей материнской плате. То есть поиск не только отдельного контроллера, но и идентичной материнской платы, в случае выхода её из строя.

В целом, как мне кажется, решение на базе fake RAID имеет право на жизнь. Конечно, необходимо настроить систему резервного копирования для устранения минусов.

Еще хочу отметить, что система, установленная на данный RAID массив, работает гораздо веселее, даже по субъективным ощущениям. :)

Автор: Шиболов Вячеслав Анатольевич

Настольная книга SAP-консультанта

Недавно дошли руки до книги, которая давно лежала на полке, Джон Рид и Майкл Доан "Настольная книга SAP-консультанта".

Авторы книги американские эксперты в области SAP-консалтинга. Причем, занимаются они, в основном, подбором персонала, вопросами обучения и карьеры в области SAP.

Впервые книга была издана в США в 1999 году, потом переиздана в 2004. На русский язык была переведена и издана в 2008 году. Люди, которые занимались локализацией, в предисловии делают упор на то, что российский рынок SAP отстает от американского примерно на 10 лет. Этим они пытаются объяснить, чем же может быть полезна данная книга для читателей из нашей страны с учетом года издания оригинальной версии.

По поводу содержания. В книге 270 страниц, которые, на мой взгляд, можно было бы сократить вдвое. Авторы раскрывают кухню SAP консалтинга, разъясняя такие моменты, как работа в различных компаниях (консалтинговые компании "большой четвертки", кто входит в "большую четвертку", малые и средние консалтинговые компании, компании-клиенты, внедряющие SAP продукты), SAP-фриланс, построение карьеры в SAP, сравнение актуальности и даже материального вознаграждения в тех или иных модулях SAP системы.

Так же освещены общие моменты: как правильно составлять резюме, проходить телефонное и личное собеседование. Не обошли авторы тему обучения в SAP AG или сторонних компаниях, сертификацию.

В конце книги приведены примеры из работы самих авторов. Как, я и упоминал, они занимаются разработкой стратегии развития SAP консультантов и поиска работы. То есть приведены примеры реальных людей, которые пытались менять работу, следуя той или иной линии в карьере. А авторы помогали им советами, раскладывая по полочкам плюсы и минусы того или иного решения/компании.

В целом, книга неплохая. Даже несмотря на американское происхождение и "не первую свежесть". Есть что почерпнуть для себя и увидеть плюсы и минусы внутренней кухни SAP консалтинга. Некоторые моменты, такие как, уровень доходов консультантов на американском рынке в 1999-2004 годах, представляют очень низкую ценность для нас. Некоторые моменты, как например, как составлять резюме или проходить собеседование, являются общими и не SAP-специализированными. Но есть и действительно реальные моменты из жизни SAP консультантов, мысли о карьерном развитии и о том, куда же движется рынок SAP.

Вывод: чем младше вы в карьерном плане, как SAP консультант и как IT специалист, тем полезнее вам будет эта книга.

Я был удивлен, когда обнаружил, сколько эта книга стоит в магазинах. Наверное, каждое слово "SAP", встречающееся в книге, добавляет 1 рубль к цене. :)

Я готов, подарить свой экземпляр тому, кто следующий купит один из моих пакетов практических заданий по администрированию SAP систем.

Автор: Шиболов Вячеслав Анатольевич

35 лет или как я попал в SAP

День рождения хороший повод оглянуться назад и вспомнить прошлое. :)

В 2002 году я закончил Казанский Государственный Технический Университет им. Туполева (бывший КАИ) по специальности 2201 "Вычислительные машины, комплексы, системы и сети". Специальность довольно обширная, как я сейчас понимаю, являющаяся отличной базой для будущего системного администратора. Но тогда я совершенно не знал чему меня учили, к чему готовили, и кем мне теперь работать. Конечно, я был очень увлечен компьютерами, программированием, железом (причем на тот момент без доступа в Интернет), но узкой специализации во время обучения не приобрел. Подрабатывал я во время обучения мало, и то - только на "грязных" работах, типа прокладки ЛВС с перфоратором наперевес. :)

После окончания института я вернулся в родной город Альметьевск и начал искать работу. Градообразующим предприятием и самым "престижным" местом работы в городе являлось ОАО "Татнефть". Туда я и пробовал устроиться. Набор во всю компанию в тот период был закрыт, но, благодаря небольшим связям и моему диплому "с отличием", для меня сделали небольшое исключение, и в мае 2002 года я устроился в подразделение "ТатАСУнефть" в отдел "Unix систем и баз данных". На тот момент отдел включал в себя три бюро: "Unix систем", "Баз данных ORACLE" и "Систем SAP", руководил отделом хороший человек - Ильгам Мухаметзянов. На собеседовании (если это можно так назвать) он меня спросил: "А слышал ли ты что-то про систему SAP?". На что я ответил, что знаю что такое САПР, но про SAP слышу впервые. :)

Свой трудовой стаж я начал в бюро "Unix систем", где и началось моё путешествие в мир стройных, элегантных операционных систем семейства Unix. В ОАО "Татнефть" этот мир был представлен в основном HP-UX на оборудовании компании HP. Было так же немного FreeBSD и Linux, пару раз видел через окно консоли IBM-ский AIX. Пройдя несколько обучающих курсов в Hewlett-Packard, я проникся страстью к этим системам. Попутно мне пришлось выучить язык Perl и Web-программирование, когда я разрабатывал централизованную систему сбора статистики о загрузке серверов под управлением HP-UX и записей системного журнала.

Но все течет, все меняется. Через год моей "спокойной" и плодотворной работы в вышеупомянутом отделе в ОАО "Татнефть" началась очередная реорганизация подразделений/отделов (что, кстати говоря, там не редкость). Это привело к тому, что к нашему отделу присоединилось бюро по администрированию серверов под управлением операционной системы MS Windows, и сменился начальник отдела. Новый начальник начал реорганизацию внутри отдела и предложил мне перейти в бюро "SAP систем". Ох, как мне тогда не хотелось этим заниматься. :) Мне так нравилась строгость Unix и аппаратная мощь оборудования HP (к слову, тогда был куплен и запущен сервер серии HP SuperDome и дисковый массив уровня XP 1024), что переходить в какой-то SAP, где ребята часто зашивались и трудились до позднего вечера и по выходным, не прельщало совсем. Но выбор за меня был сделан, и меня "уговорили", пообещав, что так как системы SAP работают на тех же серверах HP, то я буду заниматься и ими тоже.

Я начал работать с SAP системами под руководством хорошего специалиста и моего друга Вахита Хисамова (привет Вахит, если ты читаешь этот пост). Прошел несколько обучающих курсов в SAP AG. В данный период времени я занимался на 50 % операционными системами и серверами, и только на 50 % системами SAP.

В конце 2003 года я решил переехать в Москву. Стоит отметить, что в нашем отделе были собраны хорошие специалисты в области администрирования Unix-систем, баз данных Oracle, систем SAP, и нередки были разговоры о том, что в Москве такие специалисты зарабатывают гораздо больше. Я бы сказал, что отношение зарплат было минимум 1 к 6 не в пользу работы в Альметьевске. Поэтому Москва для всех была "мечтой". И сейчас уже, как минимум, 3 специалиста из того отдела работают в Москве. Отпускать меня очень не хотели, был большой скандал, так как если вы посмотрите мое резюме, то увидите, что за эти 2 года в мое обучение было вложено очень много долларов и евро (9 курсов в HP и SAP AG). Но ничего мне предложить не смогли и в феврале 2004 года я уехал.

В Москве, оказавшись единственным специалистом по Basis в небольшой консалтинговой компании, мне пришлось заняться SAP системами на все 110 %. Это был огромный толчок в моем профессиональном росте, когда на меня легла вся ответственность и рядом не было администраторов, на которых можно "свалить" часть работы. И опять мне повезло. У меня был очень хороший руководитель SAP практики, который в меня верил и поддерживал. Ну мне так кажется. :)

Не буду превращать этот пост в мемуары и на этом закончу. Мое полное резюме можно найти тут. 

Напишите, пожалуйста, в комментариях, а как вы попали в SAP?

Автор: Шиболов Вячеслав Анатольевич

Опрос: важно ли высшее образование

Хотелось бы узнать ваше мнение по поводу высшего образования в целом, ВУЗ-ов и конкретно вашего случая - где учились, как оцениваете потраченные на это 5-6 лет, используете ли в своей работе полученные знания.

Опрос закрыт.

Если есть желание что-то сказать по этой теме дополнительно - пишите в комментариях.
Спасибо. :)

Автор: Шиболов Вячеслав Анатольевич

Программное обеспечение для администратора

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

• MS Windows XP Professional SP3 (с Windows 7 очень быстро вернулся опять на XP).
• MS Office 2003 + пакет обеспечения совместимости с файлами MS Office 2007.
• архиватор 7-zip.
• двух-панельный файловый менеджер Far (активно использую встроенный FTP-клиент).
• для коннекта к серверам использую: Windows Remote Desktop (протокол RDP), RAdmin, RealVNC, Xmanager (триальная версия) и PuTTY (telnet, ssh).
• SAP GUI 7.20 for Windows.
• почтовый клиент Mozilla Thunderbird (свежий).
• интернет-браузер Mozilla Firefox (свежий). Использую для постоянной работы. Пробовал перейти на Google Chrome. Он очень быстрый, имеет свежий лаконичный дизайн, приятные мелочи (такие как свой интерфейс печати, синхронизация пользовательских данных между разными машинами), но, к сожалению, не поддерживается SAP, в отличии от Firefox, и все таки пока некорректно отображает некоторые сайты (например, PlatinHTML HELP SAP системы).
• интернет-браузер MS Internet Explorer 8 (запасной вариант).
• чтение документации Adobe Reader, WinDJView.
• SAP Download Manager для скачивания дисков и пакетов SAP.
• для связи Skype, MirandaIM (ICQ).
• ORACLE VirtualBox для виртуализации, тестирования, обучения. В последнее время перешел на учебный сервер, на рабочей станции не использую виртуальные машины.

Из дополнительного:

• для просмотра/обработки изображений IrfanView.
• просмотра видео, прослушивания аудио VLC media player.

Основные принципы выбора ПО для работы: меньше программ, но больше функций; бесплатные (лучше open-source); легкие.

А какие полезные программы используете вы? Буду рад, если посоветуете что-то в комментариях.

Автор: Шиболов Вячеслав Анатольевич