Это была достаточно молодая организация. Основной её задачей на момент начала моей деятельности было сопровождение электронного документооборота органов государственной власти (ОГВ).

Моей же целью было создать ЦОД и организацию, его обслуживающую. В ЦОД должны были переехать все имеющиеся государственные информационные системы, а также разместиться все вновь создаваемые. В то время как раз шёл бурный рост электронных государственных услуг и общей автоматизации органов государственной власти.

В то время понимания того, что такое электронное правительство особенно не было. Главное, что было понимание того, что «не место красит человека, а человек — место». Команда у меня была небольшая, состоящая из меня, но для начала этого вполне хватало, тем более автоматизация рутинных процессов позволяет избежать лишнего раздувания штата.

А вот так выглядел ЦОД перед моим уходом, июль 2014 года.

До перехода в эту организацию я работал ведущим специалистом отдела сопровождения одного из крупных банков. И этот опыт был очень кстати для внедрения в ОГВ. Вообще, банковская сфера с точки зрения ИТ мне очень понравилась, но это отдельная история. Здесь же мне предстояло исполнить в какой-то степени функции «серого кардинала»: отсутствующего в штате главного инженера.

Создаваемый мной ЦОД должен быть не просто надёжным, а катастрофоустойчивым, производительным и дешевым. Мне кажется именно поэтому меня пригласили сюда поработать, т. к. нужно было сначала добиться эффективного использования того, что уже есть. А у интеграторов было только одно предложение: если дадите ещё денег… В том числе и поэтому к услугам интеграторов и т. п. подрядчиков я не прибегал.

Так как, все ресурсы фактически переезжали в наше «облако» — пришлось ввести понятие «государственное частное облако», ввиду того, что имеющийся понятийный аппарат, состоящий из «публичного» и «частного» «облаков», не в полной мере удовлетворял логике предоставления ресурсов. Снаружи это было «частное облако», изнутри — «публичное», но только для ОГВ. В связи с этим были некоторые особенности лицензирования ПО.

С некоторыми концептуальными моментами успели определиться ещё до моего прихода в организацию, их пришлось принять как данность. Проект развивался в тесном сотрудничестве с IBM, Microsoft, Cisco. Почему именно эти вендоры? Для меня — так исторически сложилось. Жалею ли я об этом? Нисколько! Можно ли было использовать других вендоров? Конечно, например, DELL, HP или любого другого, а также их произвольные сочетания.

В качестве платформы виртуализации была закуплена — VMWare, на тот момент 5 версии. Тут, думаю, все согласятся, что выбор практически безальтернативен.

При первоначальном аудите имеющихся мощностей в стойках по городу я обнаружил пару шасси IBM BladeCenter: E и H. Шасси были укомплектованы лезвиями HS22, далеко не самыми плохими, твёрдая середина в то время. Состояние, конечно, было несколько плачевным, особенно раздражали горящие индикаторы ошибок.

В качестве системы хранения на одной площадке была установлена полка DS3512, подключенная по оптике, с установленными 2Тб дисками. На другой площадке была установлена полка DS3512 и DS3524.

На резервной площадке свободное место было распределено так, что VMWare без ручного вмешательства не стартовала: обнаруживала другие установленные копии и останавливалась, помогал только запуск с соответствующим ключом. Само же распределение шло по принципу: каждой виртуальной машине свой LUN. Когда понадобилось выделить дополнительное место виртуальной машине, а на имеющемся LUN’е его не было…

Между собой площадки были соединены тоненькой сетью передачи данных шириной в 1Гбит/с. Никакой выделенной сети для работы той же виртуализации и хождения служебного трафика не существовало.

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

Я решительно приступил к работам.

Начало пути

В такой, в будущем серьёзной, организации на момент моего прихода от ИТ инфраструктуры не было ровным счётом ничего: одинокий умный коммутатор, одноранговая сеть, общие ресурсы на каждом рабочем месте… В общем всё именно так, как вы себе представляете положение дел в регионе.

Соответственно первоначально была быстро создана инфраструктура предприятия. Для чего было упорядочено всё, что имелось на тот момент. Вооружившись сетевым тестером, я нашёл и подписал все провода. Т.к. на момент прокладки проводов никакого плана рабочих мест не было — где-то вместо телефонов были ПК, где-то вообще не хватало проводов и много других стандартных «прелестей».

К сожалению, при проектировании серверного помещения будущего ЦОД никто не сделал ни фальш-пол, ни проволочного лотка под потолком. Естественно, денег ни на то, ни на другое уже не было, поэтому пришлось наводить красоту собственными силами.

Так как просто укоротить провода на тот момент мне никто не разрешил: «вдруг придётся переместить стойку в дальний угол помещения, как тогда быть?» — пришлось под потолком сделать 110-й кросс, от которого уже опускать провода в стойку. Чтобы на случай перемещения стойки короткие провода можно было демонтировать из кросса, установив туда более длинные.

Вид настенной 110-й кросс панели в процессе монтажа, а также нож для заделки проводов.

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

Вид стойки до и после укладки.

В стойке я обнаружил офисную мини АТС Panasonic KX-NCP500, укомплектованную 4 городскими и 8 внутренними линиями. Внутренние телефонные линии меня интересовали меньше всего, всё таки это была IP АТС: постепенно я всё перевёл на VOIP.

Так как серьёзного опыта в настройке АТС у меня не было, пришлось немного повозиться. Одно только понимание необходимости поднятия собственного STUN-сервера чего стоило…

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

О самой сети ОГВ было понятно только то, что она где-то есть. Всю топологию сети мне пришлось восстанавливать по конфигам оборудования, тщательно зарисовывать и документировать. Конфиги постепенно принимали человеческий вид, появлялись description, логика именования.

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

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

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

В общем первые пара месяцев работы прошли, считаю, очень плодотворно.

Первый этап

Первоначально ЦОД, кроме как для работы межведомственного документооборота, больше ни для чего не использовался. Бесспорно, документооборот — это одна из самых важных частей работы органов государственной власти. Часто именно из-за сложностей документооборота возникает множество проблем в работе нашего государства и именно электронный документооборот является выходом из сложившейся ситуации.

Я думаю, самый интересный вопрос: на чём же работает электронное правительство в ЦОД?

Сам ЦОД состоит из нескольких географически распределённых площадок, таким образом реализуется концепция катастрофоустойчивости, работа ведётся 24/7/365. Площадки между собой были соединены основной магистралью на 32 одномодовых волокна.

Основу ЦОД составляют попарно распределённые по площадкам лезвия IBM HS22 и HS23 (ныне Lenovo). В каждое шасси помещается 14 лезвий, на начальном этапе было установлено по пять лезвий.

В каждом лезвии по два процессора, если не ошибаюсь, E5650 (6 ядер, 12Мб кэш), ОЗУ под завязку 192Гб. Лезвия без дисков, внутри я принял решение установить USB-flash с образом VMWare чтобы максимально разделить исполнение и хранение, журналы пишутся на общее хранилище, аплинк каждого лезвия — 2Гбит/с. Аплинк может быть поднят до 10Гбит/с путём установки соответствующего коммутатора в шасси и сетевой карты в каждом лезвии.

Наша основная 32-х волоконная магистраль.

В качестве ОС — VMWare vSphere (когда я уходил была 5.5) Standard. В более продвинутой версии я тогда не видел смысла: предлагаемого функционала хватало с избытком. А то, чего не хватало — можно было написать самостоятельно.

В дальнейшем количество лезвий было увеличено за счёт немного более мощных серверов IBM HS23.

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

Охлаждение было также различно. На основной площадке это были настенные промышленные кондиционеры с блоком балансировки. Температура поддерживалась на уровне 21 градуса. На другой площадке это были промышленные напольные кондиционеры и подпольным подводом воздуха.

IBM SVC. Контроллер нашей системы хранения.

Система хранения масштабируемая, на базе контроллера IBM SVC, что позволило добиться резервирования аналогичного RAID 6+1, резервирование по нескольким путям, межблочное соединение по оптике 8Гбит/с аплинки. Любая часть ЦОД могла в любой момент перейти в режим автономной работы в случае аварии или проведения регламентных работ.

В функционирующем ЦОД виртуализованы почти все физические ресурсы: хранение виртуализировано на базе IBM SVC; процессорные и ресурсы оперативной памяти виртуализированы на базе VMWare vSphere. Если принять за виртуализацию использование VLAN на коммутаторах, то можно считать, что и сетевая инфраструктура также виртуализирована.

Практически всё оборудование, поддерживающее удалённое управление, я подключил к сети и настроил. На удалённых площадках всё работает в том числе через управляемые электрические розетки (появились они правда позже, на втором этапе), поэтому в случае сбоя какого-либо оборудования без удалённого управления — его возможно перезагрузить по питанию.

ЦОД создавался в несколько этапов. Первый этап включал в себя наведение порядка и создание облачной инфраструктуры. Первоначальной целью было создание уровня виртуализованного хранилища на базе IBM SVC.

По мере реализации плана к нам на площадку начали переезжать сервера, ранее располагавшиеся в сторонних организациях. Так к нам переехало несколько старых серверов IBM с работающими сервисами, которые потребляли и грелись больше, чем одно шасси BladeCenter. Конечно, постепенно сервисы с них переехали в «облако».

Первым делом — план. К тому времени я уже мог работать так, как считаю нужным (всё таки за плечами уже было несколько реализованных проектов, да и то, что есть работает без сбоев — доверие заслужил). Поэтому сначала стойки я собрал в редакторе, попутно обсудив и поспорив с собой.

Процесс монтажа оборудования в стойку.

Монтаж производился уже по стандартам, best practices и рекомендация описанным, в том числе, в IBM RedBook. Конечно, в первый раз моё «давайте прочтём документацию» было поднято на смех, но после того, как «методом научного тыка» сервера отказывались встать на место потому, что для одного расстояние между направляющими слишком большое, для другого слишком маленькое — я нашел в редбуке стандартные размеры для сборки стоек, после этого всё сошлось с первого раза.

Первый этап ЦОД, июнь 2013 года. На заднем плане бубен Верховного Администратора.

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

ЦОД уже на этом этапе стал показательным и регулярно принимал посетителей для демонстрации того, как должна работать и выглядеть ИТ инфраструктура.

Так выглядеть ИТ инфраструктура не должна. Снимок сделан на второй день моей трудовой деятельности, 2012 год.

В процессе реализации ЦОД мне стало понятно, что ресурсы необходимо эффективно доставить до потребителей — органов государственной власти. Тем более, что некоторые «своеобразно» написанные информационные системы, переехавшие в облако, гоняли очень большие объёмы информации по сети.

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

Почему это не было сделано изначально? Ответ простой: не было квалифицированных специалистов для этой работы, только внешние подрядчики. А они стремятся подсадить на аутсорс.

На этом моменте мне пришлось планировать и строить инфраструктуру провайдера. При этом пришлось провести аудит многих сетей ОГВ. Конечно, в некоторых ОГВ были достаточно сильные ИТ-службы (например, в минфине, в минобре, в аппарате правительства и других). Но были и откровенно слабые, где не могли даже обжать провод. Таких приходилось брать полностью под своё крыло, благо квалификация позволяла.

Поэтому, в том числе, мне пришлось разрабатывать и типовую сетевую архитектуру ОГВ, к которой нужно было стремиться. Стандартизация и типизация — залог эффективной эксплуатации. По моим предварительным расчётам на одного человека в нашей организации должно было приходиться минимум 100-150 объектов администрирования.

Конечно же в строящейся сети помимо очевидных технологий VLAN использовались и другие современные технологии облегчающие администрирование: OSPF, VTP, PVST, MSTP, HSRP, QoS, и т.д. Хотелось, конечно, поднять statefull резервирование, но, к сожалению, не хватало аппаратных ресурсов ASR. До MPLS добраться, к сожалению, не получилось. Да и не было необходимости.

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

Общий аплинк между площадками на первом этапе составлял всего-навсего несколько гигабит. Но уже я выделил канал для работы vSphere.
Сама же сеть получилась географически сильно распределённая, включающая достаточно большое количество удалённых узлов подключенных по L2/L3 VPN.

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

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

Второй этап

На втором этапе нам уже пришлось наращивать аппаратные мощности нашего ЦОД. Расширение мощностей потребовало смены шасси с модели E на H, перемонтаж существующих стоек. Было увеличено дисковое пространство за счёт увеличения количества полок с HDD.

Полки с жёсткими дисками IBM DS3512 и вверху видна полка DS3524.

К нам переехало ещё несколько физических серверов. Значительно возросло количество виртуальных машин.

Было добавлено средство резервного копирования на базе ленточной библиотеки IBM TS3200.

На переднем плане ленточная библиотека IBM TS3200.

Естественно, монтаж нового оборудования я начал с предварительного планирования. Здесь уже пришлось стойки моделировать с обеих сторон.

Планирование расширения ЦОД.

Переезд был совершен в кратчайшие сроки. Так как к тому моменту виртуализация функционировала в полном объёме, процесс переезда прошёл абсолютно незаметно, ведь перед переносом и отключением оборудования на одной площадке все виртуальные сервера мигрировали на другую, а по окончание работ — всё возвращалось на круги своя.

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

Вид стоек после расширения ресурса, 2014 год.

А так как к тому моменту наш ЦОД стал уже образцово-показательным, я решил уделить внимание деталям: имеющиеся свободные юниты были закрыты чёрными фальш-панелями, а там где была необходима вентиляция были установлены перфорированный фальш-панели. Даже крепёжные болты, которыми оборудование крепится в стойке, я снял и покрасил из баллончика в чёрный цвет. Мелочь, а приятно.

Вид стоек на резервной площадке в процессе монтажа (слева) и по окончание (справа).

Для того, чтобы избавиться от лежащих всюду медиа конвертеров были приобретены пара шасси D-Link DMC-1000, в т.ч. обеспечивающих резервирование питания медиа конвертеров за счёт пары блоков питания.

Параллельно велись работы и по модернизации сети. Кольцо ядра сети передачи данных я замкнул на скорости 20 Гбит/с между площадками. Путём оптимизации имеющегося оборудования служебная сеть для работы виртуальной инфраструктуры обзавелась 10 Гбит/с аплинком, ввиду чего стало возможным мигрировать практически все лезвия одновременно, пропускной способности было достаточно.

Очень приятной оказалась совместимость оборудования SNR с имеющимся оборудование Cisco и Brocade. Конечно, в своё время наличие оборудования Brocade в шасси для меня было неприятным сюрпризом, т. к. ранее мне не приходилось с ним работать. Но, к счастью, наличие знаний о принципах работы сети позволило быстро разобраться и с ним.

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

Везде должен быть порядок.

Тем временем

Параллельно физическому созданию ЦОД и сети ОГВ шла разработка программного обеспечения для функционирования электронного правительства, в которой мне также довелось поучаствовать. Как с точки зрения внедрения и развёртывания, так и с точки зрения идеологического сопровождения. За поддержку верной идеологии большое спасибо тогдашнему руководству.

Мне регулярно приходилось проводить аудит баз данных, гонять разработчиков, чтобы они пользовались индексами в базах данных, отлавливать ресурсоёмкие запросы и оптимизировать узкие места. Одна из систем кроме первичных ключей не имела больше никаких индексов. Результат — при начале интенсивной эксплуатации производительность БД стала резко деградировать, пришлось самостоятельно насаждать индексы.

Благодаря своевременному вмешательству в процесс разработки, все разрабатываемые государственные системы были сделаны кросс-платформенными. И там, где не было острой необходимости использовать в качестве базы Windows – всё работало под управлением систем семейства Linux. Как оказалось, основным препятствием в создании кросс-платформенных приложений было использование неуниверсальной нотации в написании путей. Часто после замены одного слеша на другой государственная система резко становилась кросс-платформенной.

Созданная сеть охватывала так или иначе практически все ОГВ, я был готов начать обеспечивать подключение к сети интернет, заниматься фильтрацией трафика, его антивирусной защитой, препятствовать атакам снаружи и изнутри ОГВ. В том числе это должно было обьеспечить значительную экономию бюджетных средств за счёт более эффективного использования пропускной способности канала.

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

Третий этап модернизации ЦОД должен был стать для меня самым интересным. К концу второго этапа был налажен диалог с разработчиком отечественных процессоров Эльбрус, был получен доступ к тестовому стенду и стало понятно, что как минимум треть функционала эксплуатируемых систем можно перевести на отечественную аппаратную платформу! Как раз в следующем, 2015 году, должна была выйти новая аппаратная версия отечественного процессора… В бюджет следующего года были заложены суммы на приобретение серверов…

Подводя итоги

Но моим мечтам о переводе государственных услуг на отечественную аппаратную платформу не суждено было сбыться (как и другим планам), т. к. я был вынужден сменить работу на не менее интересную, но более высокооплачиваемую. Жаль, конечно, я считаю, что мог бы сделать неплохой толчок для внедрения отечественной аппаратной платформы. Тем более это было ещё до волны импортозамещения.

На момент окончания моего трудового пути в данной организации на базе нашего ЦОД я успел спланировать, создать, развернуть, либо принять участие в создании:

• ЦОД и сеть ОГВ (http://cit-sk.ru/);
• региональный портал государственных и муниципальных услуг (http://gosuslugi26.ru/);
• портал «Народный контроль Ставропольского края» (http://control26.ru/, изначально моя разработка);
• система электронного документооборота;
• портал ОГВ Ставропольского края (http://stavregion.ru/);
• сеть межведомственной IP-телефонии (Asterisk);
• защищённая сеть ОГВ (VipNET);
• сеть информационных киосков для доступа к гос. услугам в электронном виде («инфоматы»);
• почтовую систему ОГВ (@stavregion.ru);
• региональный узел ГИС ГМП (обработка государственных и муниципальных платежей);
• ГАС «Управление»;
• информационная система Министерства образования СК;
• VDS-хостинг сайтов для нужд ОГВ (я поддерживал любую платформу);
• справочный сетевой телефонный узел;
• региональная система межведомственного электронного взаимодействия (РСМЭВ);
• основные и резервные контроллеры доменов;
• реестр государственных услуг СК;
• централизованные службы обновления WSUS и антивирусов;
• мониторинг узлов и сбор статистики;
• и т.д.

В общей сложности на наших 7 парах физических серверов работало тогда более 120 виртуальных серверов, используя порядка 30-40% ресурсов ЦПУ и ОЗУ, порядка 50% системы хранения. В общей сложности на тот момент штатная численность у нас была порядка 30-35 человек, включая весь административно-управленческий аппарат, службу обработки звонков.

Эффективность использования, я уверен, на лицо.

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

Благодарности

• Во-первых, Вам, дорогой читатель, за то, что дочитали до этого места.
• Моей жене за помощь и поддержку.
• Руководству ГКУ СК «Краевой центр информтехнологий» за оказанное доверие.
• Руководству Министерства промышленности, энергетики и связи Ставропольского края за административную поддержку.
• Всем коллегам, с кем посчастливилось тогда поработать.