«Не место красит человека, а человек — место»
Все мы регулярно видим обзоры разного рода Центров Обработки Данных (ЦОД): большие, малые, подводные, арктические, инновационные, производительные и т. д. Однако, практически нет обзоров тех невидимых героев, что работают на наше с вами благо в государственных застенках, а тем более — в регионах. Поэтому я хочу поделиться собственным опытом создания ЦОД в Ставропольском крае.
Знакомство
Был тёплый летний день, как сейчас помню — 18 июня 2012 года. В тот день, зайдя в стены нашего будущего ЦОД, я увидел именно эту картину, которая, честно говоря, повергла меня в небольшой шок. Знакомьтесь, ГКУ СК «Краевой центр информтехнологий» на заре своего существования. Все изображения кликабельны.
Так выглядела единственная стойка внутри нашего будущего ЦОД в июне 2012 года.
Это была достаточно молодая организация. Основной её задачей на момент начала моей деятельности было сопровождение электронного документооборота органов государственной власти (ОГВ).
Моей же целью было создать ЦОД и организацию, его обслуживающую. В ЦОД должны были переехать все имеющиеся государственные информационные системы, а также разместиться все вновь создаваемые. В то время как раз шёл бурный рост электронных государственных услуг и общей автоматизации органов государственной власти.
В то время понимания того, что такое электронное правительство особенно не было. Главное, что было понимание того, что «не место красит человека, а человек — место». Команда у меня была небольшая, состоящая из меня, но для начала этого вполне хватало, тем более автоматизация рутинных процессов позволяет избежать лишнего раздувания штата.
А вот так выглядел ЦОД перед моим уходом, июль 2014 года.
До перехода в эту организацию я работал ведущим специалистом отдела сопровождения одного из крупных банков. И этот опыт был очень кстати для внедрения в ОГВ. Вообще, банковская сфера с точки зрения ИТ мне очень понравилась, но это отдельная история. Здесь же мне предстояло исполнить в какой-то степени функции «серого кардинала»: отсутствующего в штате главного инженера.
Создаваемый мной ЦОД должен быть не просто надёжным, а катастрофоустойчивым, производительным и дешевым. Мне кажется именно поэтому меня пригласили сюда поработать, т. к. нужно было сначала добиться эффективного использования того, что уже есть. А у интеграторов было только одно предложение: если дадите ещё денег… В том числе и поэтому к услугам интеграторов и т. п. подрядчиков я не прибегал.
Так как, все ресурсы фактически переезжали в наше «облако» — пришлось ввести понятие «государственное частное облако», ввиду того, что имеющийся понятийный аппарат, состоящий из «публичного» и «частного» «облаков», не в полной мере удовлетворял логике предоставления ресурсов. Снаружи это было «частное облако», изнутри — «публичное», но только для ОГВ. В связи с этим были некоторые особенности лицензирования ПО.
С некоторыми концептуальными моментами успели определиться ещё до моего прихода в организацию, их пришлось принять как данность. Проект развивался в тесном сотрудничестве с IBM, Microsoft, Cisco. Почему именно эти вендоры? Для меня — так исторически сложилось. Жалею ли я об этом? Нисколько! Можно ли было использовать других вендоров? Конечно, например, DELL, HP или любого другого, а также их произвольные сочетания.
В качестве платформы виртуализации была закуплена — VMWare, на тот момент 5 версии. Тут, думаю, все согласятся, что выбор практически безальтернативен, т.к. прочие не предоставляли возможностей аналогичных Fault Tolerance.
При первоначальном аудите имеющихся мощностей в стойках по городу я обнаружил пару шасси IBM BladeCenter: E и H. Шасси были укомплектованы лезвиями HS22, далеко не самыми плохими, твёрдая середина в то время. Состояние, конечно, было несколько плачевным, особенно раздражали горящие индикаторы ошибок.
Вид одной из имевшихся в июне 2012 года стоек. Обратите внимание на монтаж оборудования «через квадратик», особенно оборудования Cisco.
В качестве системы хранения на одной площадке была установлена полка DS3512, подключенная по оптике, с установленными 2Тб дисками. На другой площадке была установлена полка DS3512 и DS3524.
На резервной площадке свободное место было распределено так, что VMWare без ручного вмешательства не стартовала: обнаруживала другие установленные копии и останавливалась, помогал только запуск с соответствующим ключом. Само же распределение шло по принципу: каждой виртуальной машине свой LUN. Когда понадобилось выделить дополнительное место виртуальной машине, а на имеющемся LUN'е его не было…
Между собой площадки были соединены тоненькой сетью передачи данных шириной в 1Гбит/с. Никакой выделенной сети для работы той же виртуализации и хождения служебного трафика не существовало.
После краткого ознакомления и аудита ИТ инфраструктуры (а кратким он был, т. к. практически никакой инфраструктуры не существовало) был сделан вывод, что передо мной классический пример того, как делать не надо. В наличии не было никаких схем, ни сопроводительной документации, даже пароли администратора были известны далеко не все, их пришлось сбрасывать и восстанавливать.
Я решительно приступил к работам.
Начало пути
В такой, в будущем серьёзной, организации на момент моего прихода от ИТ инфраструктуры не было ровным счётом ничего: одинокий умный коммутатор, одноранговая сеть, общие ресурсы на каждом рабочем месте… В общем всё именно так, как вы себе представляете положение дел в регионе.
Соответственно первоначально была быстро создана инфраструктура предприятия. Для чего было упорядочено всё, что имелось на тот момент. Вооружившись сетевым тестером, я нашёл и подписал все провода. Т.к. на момент прокладки проводов никакого плана рабочих мест не было — где-то вместо телефонов были ПК, где-то вообще не хватало проводов и много других стандартных «прелестей».
К сожалению, при проектировании серверного помещения будущего ЦОД никто не сделал ни фальш-пол, ни проволочного лотка под потолком. Естественно, денег ни на то, ни на другое уже не было, поэтому пришлось наводить красоту собственными силами.
Так как просто укоротить провода на тот момент мне никто не разрешил: «вдруг придётся переместить стойку в дальний угол помещения, как тогда быть?» — пришлось под потолком сделать 110-й кросс, от которого уже опускать провода в стойку. Чтобы на случай перемещения стойки короткие провода можно было демонтировать из кросса, установив туда более длинные.
Вид настенной 110-й кросс панели в процессе монтажа, а также нож для заделки проводов.
Также сразу было определено, что будет вестись цветовая маркировка патч-кордов, т. к. в наличии был только синий и красный кабель, телефонию пришлось сделать красным, а всё что касается сети — синим.
Вид стойки до и после укладки.
В стойке я обнаружил офисную мини АТС Panasonic KX-NCP500, укомплектованную 4 городскими и 8 внутренними линиями. Внутренние телефонные линии меня интересовали меньше всего, всё таки это была IP АТС: постепенно я всё перевёл на VOIP.
Так как серьёзного опыта в настройке АТС у меня не было, пришлось немного повозиться. Одно только понимание необходимости поднятия собственного STUN-сервера чего стоило…
Как таковой собственной сети у организации не оказалось, все компьютеры были расположены в одном большом интранете. Меня, как человека, не по наслышке знающего об информационной безопасности, это не устраивало: на границе сети я поставил и настроил маршрутизатор на базе FreeBSD, а саму сеть сегментировал для возможности полного контроля межсетевого взаимодействия. При подобном подходе обычно страдает только один сегмент.
О самой сети ОГВ было понятно только то, что она где-то есть. Всю топологию сети мне пришлось восстанавливать по конфигам оборудования, тщательно зарисовывать и документировать. Конфиги постепенно принимали человеческий вид, появлялись description, логика именования.
Спустя почти полгода я наконец нашёл документацию по сети ОГВ. Но, к сожалению, она на 90% не соответствовала тому, что было по факту. Сделана она была очень качественно, это был один из немногих документов, по которым можно было работать. Но никто, судя по настройкам, не работал.
По мере обследования сети все узлы я привёл в актуальное состояние, т. к. практически на всём оборудовании были установлено сильно устаревшее программное обеспечение. Где-то в этом не было необходимости, а где-то это исправило имеющиеся проблемы.
Старый (слева, 2012 год) и новый (справа, 2016 год) вид главной страницы сайта.
Также был разработан сайт, при этом параллельно были подняты собственные 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 объектов администрирования.
Одна из поставок оборудования Cisco.
Конечно же в строящейся сети помимо очевидных технологий 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 человек, включая весь административно-управленческий аппарат, службу обработки звонков.
Эффективность использования, я уверен, на лицо.
На самом деле можно ещё очень много рассказать в подробностях о становлении практически каждого из сервисов, тогда получится достаточно увесистый том воспоминаний.
Благодарности
- Во-первых, Вам, дорогой читатель, за то, что дочитали до этого места.
- Моей жене за помощь и поддержку.
- Руководству ГКУ СК «Краевой центр информтехнологий» за оказанное доверие.
- Руководству Министерства промышленности, энергетики и связи Ставропольского края за административную поддержку.
- Всем коллегам, с кем посчастливилось тогда поработать.
Комментарии (69)
osipov_dv
20.06.2016 14:35+1такой бардак бывает не только в госах, в 2009 аналогично поднимал коммерческую структуру, причем финансово успешную.
POS_troi
21.06.2016 07:35Большая пасажиро-транспортная компания, работает в 18-и городах, инраструктура собрана из г-мна и палок =/
Landgraph
21.06.2016 08:38И, как обычно, вся аргументация, уверен, сводится к «ну ведь работает же»…
POS_troi
22.06.2016 12:47не, всё делалось вчерашним днём — восстанавливалось после боевых действий.
Разграбили многое поэтому в тесных финансовых рамках и сроках всё восстанавливалось.
Да работает, глючит переодически, вот теперь нужно как-то почуток приводить всё в порядок.
amarao
20.06.2016 16:05У меня внезапный вопрос: а почему одни и те же люди занимаются внешним видом стоек и настройкой сети? В коммерческих сетях давно есть разделение полномочий: есть люди, которые хорошо знают как должны выглядеть подключения с точки зрения сети и электричества и есть люди, которые хорошо знают как настраивать сети. Когда две эти компетенции пересекаются — они никаким образом не делают общую компетенцию лучше, так как никакой синергии между двумя этими компетенциями нет.
(Вопрос: почему не были использованы мощности коммерческих ДЦ для размещения?)
Ch4r1k
20.06.2016 16:41Смею предположить — Потому что государство… Ну и до кучи, все что государственное, должно быть у государства, а не у держателей коммерческих ДЦ как бы.
Landgraph
20.06.2016 17:38Читал где-то полгода назад о том, что есть/были планы всё перевести в подконтрольные государству ЦОД… Информации о том, как успехи, найти не смог.
Alexsey
20.06.2016 20:32Каждому ОГВ дали время до, если не ошибаюсь, середины 2017 года на обдумывание сколько и чего требуется от ростелекома чтобы переехать к ним. Что будет дальше пока не понятно.
Landgraph
21.06.2016 08:43Ооооо… Хотел бы я посмотреть на эти хотелки. Помню, как мне носили заявки на наши ресурсы: взвесьте нам десяток топовых ксеонов, пару сотен гигабайт ОЗУ, ну и пару десятков терабайт на первом raid… Но после разъяснительной беседы и пары вопросов о нагрузках и методах подсчёта планируемого потребления это всё умещалось на дохленькой однопроцессорной виртуалке с 512 ОЗУ и 50Гб диска. И работало годами.
Думаю, при переезде в Ростелекомовские ЦОД будет так: любой каприз за ваши деньги. Под каждую ГИС отдельный ЦОД? Всегда пожалуйста!
Ra-Jah
20.06.2016 16:46+2Новый императорский ЦОД готовили к открытию три года. Наконец, все работы были завершены, и император пригласил всю знать полюбоваться красотой ЦОДа.
Все были в восторге и рассыпались в комплиментах. Но императора интересовало мнение Мастера Лин-чи, который считался непревзойдённым знатоком этого вида искусства. Когда император обратился к Лин-чи, все присутствующие обернулись, и воцарилась тишина. Лин-чи ответил:
— Странно, но я не вижу ни одного белого болта в черных стойках. Как жизнь может существовать без смерти? Из-за того, что здесь нет обрезков изоляции UTP5, ЦОД мёртв. Я думаю, что сегодня утром его очень тщательно подметали. Прикажите принести немного RJ-45 измазанных в побелке.
Когда разноцветные кусочки проводов витой пары принесли и разбросали, ветер из кондиционера начал играть ними. Хруст мусора под ногами — и ЦОД ожил!
Мастер сказал:
— Теперь всё в порядке. Ваш ЦОД прекрасен, но он был слишком ухожен. Искусство становится величайшим, когда не обнаруживает себя.Landgraph
20.06.2016 17:16В каждой шутке есть доля шутки, пару раз действительно спрашивали: скажите честно, а он вообще работает или только лампочками мигает?
Vanor
20.06.2016 16:49+1Один из вопросов в бюджете, он здесь и рассмотрен в том числе, можно нанять интегратора в котором будут отдельные спецы по кросам, панасоникам, цискам и броадвелам, возможно даже с высокой компетенцией, вопрос в цене(тут описанный первый этап выходит 10млн, при их подключении), да без того кто понимает в разных областях, т.е. задаст стандрат(суть тех.дир.), получится как в самом начале: «вдруг придётся переместить стойку в дальний угол помещения, как тогда быть?»
P.S. Спасибо, автор, за этот детектив.Landgraph
20.06.2016 17:11В данном случае это является ярким примером экономического фактора. А для того, чтобы потратить эти 10 млн их нужно сначала получить, а чтобы их получить… И тут мы увидим временной фактор: когда рак на горе свистнет. Интеграторы также бывают как адекватные, так и не очень. В случае неадекватного интегратора (опыт общения имеется) процесс устранения неисправностей и внесения необходимых изменений возвращает нас к временному фактору (а часто и экономическому).
Не дай бог сейчас ещё заговорить о квалификации специалистов…
amarao
20.06.2016 17:17Вы не правильно понимаете. Не нанять специальных откатных интеграторов, а просто разметиться в коммерческом ЦОДе, который уже давно съел всех собак в округе на монтаже и обслуживании.
Landgraph
20.06.2016 17:31См. ниже. Померив расстояния по картам могу сказать, что даже на сегодняшний день размещение всего оборудования в имеющихся коммерческих ЦОД у нас не будет отвечать принципу катастрофоустойчивости. Хотя, честно говоря, я вообще не уверен, что где-то ещё в стране у нас этот принцип вообще соблюдается.
Могу точно сказать, что арендовались стойко-места в коммерческих ЦОД. Но, опять же, на момент начала работ ЦОД у нас был только один. С моей точки зрения через средства удалённого управления вообще было всё равно где физически располагается оборудование: под боком или на другом конце земли.
Landgraph
20.06.2016 16:57Спасибо за вопросы!
На первый даже не знаю как ответить. Если развёрнуто, то тянет на ещё одну статью о проблемах отрасли. Если кратко, то я думаю Вы и сами понимаете причины: экономические, кадровые, организационные, политические. Считаю ли я данную ситуацию нормальной? Нет не считаю. Каждый должен заниматься своим делом, должна быть команда. Хотя знаю людей, твёрдо считающих, что инженер — это универсальный специалист: и полы мыть, и сервера крутить.
Само решение о создании ЦОД было принято до начала моей работы. От себя добавлю, что у нас как таковых коммерческих ЦОД не было (только Синтерра, ныне Мегафон). Ростелеком открыл свой ЦОД позже государственного. Дешевых ресурсов (облачных, виртуальных) не предлагал у нас никто. Также никто не отменял условие катастрофоустойчивости, в любом случае должно было быть несколько площадок, а их физически не существовало. Возможно, если бы решение принималось сейчас, то оно было бы в пользу аренды стойко-мест. Хотя с другой стороны, государственные системы должны работать в государственном ЦОД...???
Поэтому оставался выбор: строить свой или ждать, пока ставропольский бизнес создаст условия.
Tufed
20.06.2016 16:06Читаю, читаю, и чувствую, что-то родное. Ну вот, ну где-же хоть краешек скриншота/фото с упоминанием? Ах вот оно, в конце! ...26.ru Спасибо! Оторваться от статьи не мог. Работа и правда проделана колоссальная и с применением опыта.
Spewow
20.06.2016 17:37А какие были взаимоотношения с нашими регуляторами ИБ? Проверяли ГИС?
Всякие аттестаты соответствия, наличие лицензированных средств защиты, отечественная криптография и тд.Landgraph
20.06.2016 17:46Взаимоотношения были отличные. Вкратце: проводилась реальная, а не формальная аттестация рабочих мест, даже генераторы белого шума были… По понятным причинам мне очень не хотелось бы развёрнуто отвечать на вопросы, касающиеся информационной безопасности. Прошу прощения.
gDaniCh
20.06.2016 18:00Привет! Сделано действительно много и качественно. Вопрос… Какой опыт был за плечами до этого? Сколько платили и сколько предложили на новом месте (можно хоть в процентах, хоть в литрах молока :) )? Было-ли чувство «неизвестности» в начале и чётко и уверенно шёл к цели?
Landgraph
20.06.2016 20:08Как оказалось, было очень много неиспользованного опыта: образование и программирование. Образование — инженер-системотехник (АСОУ). Но задолго до него был большой опыт программирования (до поступления в ВУЗ было что-то около 6 лет опыта). Совместно это позволяет понимать как работает та или иная технология, понял как работает — дальше уже дело техники. Программировать начал лет с 10, с 14-15 уже за деньги. Прошёл весь курс от ассемблера и машинных кодов до PHP и VBA, через C/C++, Pascal и прочие Delphi. Знания по защите информации были получены на практике. =)
Платили мало, в пределах 800-1000$. На новом месте — в два раза больше и руководящая должность, пока работал зарплата росла. Но весь рублёвый рост съел кризис. Теперь выбираю куда пойти дальше, т.к. тут в моих знаниях уже потребности нет (у нас тут VLAN — это практически инструмент дьявола, нам просто нужен интернет...) =))) Для справки: средняя зарплата в ИТ отрасли в нашем регионе сейчас порядка 20-30 тыр, тогда была 15-20 тыр.
Чувства неизвестности не было, было понимание того, что нужно сделать и несколько вариантов как это можно сделать (обычно от «написать/собрать» до «купить»), выбираем оптимальный и приступаем к работе. Жаль, что не всё успел реализовать…gDaniCh
20.06.2016 20:55Ну… С такой базой за плечами не удивительно, что всё получилось :)
Cтранно, что предложили больше чем в гос. конторе, но при этом вланов бояться… Чудаки.
Я вроде как с зп в 45 админ/хелпдескер. Вот второе конкретно так напрягает и тормозит в развитии, не заняться своими делами, всё этим манагерам неймётся что-либо сломать… Думаю в СПб твои знания выйдут в 120к+ всё ж основная магистраль именно отсюда идёт и ЦОД'ы тут постоянно строят.Landgraph
21.06.2016 08:36Спасибо! =) Желаю поменьше хелпдеска!
В своё время я фактически работал в банковском хелпдеске. Т.к. по понятным причинам программировать было нельзя, пришлось пользоваться тем, что есть — Microsoft Office + VBA. Я себе целую гору автоматизации на этом бейсике написал, что-то меня пережило ещё на несколько лет. Но основная суть была в том, чтобы автоматизировать рутинные процессы хелпдеска.gDaniCh
21.06.2016 11:46Вроде да… Видел как в армии ребята тоже писали всякое-разное на нём (https://habrahabr.ru/post/237641/), но вот сейчас даже прикинуть не могу, что же там можно автоматизировать… Есть 1С 7.7 с кучей прикруток/обработок и программистом тамошним, собственно вроде как всё пытаются на той стороне решить вопрос. Я больше с серверной зайти пытаюсь.
kvant21
20.06.2016 18:03Спасибо, красиво :)
А можете рассказать, почему были выбраны блейд-системы? Дорого ведь, а сэкономить RU цель вряд ли стояла.
И про Эльбрус, если были какие-то намётки, как примерно планировалась миграция? Насколько сильно пришлось бы менять то, что уже построено? Виртуализация там вообще бывает на аппаратном уровне? Какой софт спокойно работает, а какой — не очень? Ну и как хотя бы примерно соотносится цена/производительность с традиционными системами…
Очень интересно послушать человека, который щупал их системы вживую.Landgraph
20.06.2016 19:38Вот не могу дать пояснения по поводу Blade-систем, для меня — так исторически сложилось, я пришёл — а они уже есть. Сказать, что они были сильно дороже других систем — тоже не скажу. Для меня, кстати, немаловажным был факт меньших геометрических размеров. Я вообще думал перейти на DELL: они тогда выпустили blade-систему с большей плотностью серверов на юнит.
С использованием Эльбрусов не всё так просто. Я объективно понимал, что поставить их вместо основы для виртуализации не получится никак (кроме как экспериментально и через тернии к звёздам).
Мигрировать я планировал сервисами. Т.к. сами сервисы были кросс-платформенными — нужно было «всего лишь» добиться исполнения на Эльбрусе интересующего окружения. А потом это самое окружение выложить в общий доступ и запустить тем самым волну спроса на отечественную платформу.
На тот момент серверами на базе наших процессоров без особых проблем можно было заполнить нишу, отвечающую за криптографию — это то, что я бы крайне не хотел отдавать виртуализации.
Как сильно пришлось бы менять то, что уже построено? Ровно так же, как переезжать с сервера на Intel под CentOS на AMD под CentOS. Главное — чтобы окружение завелось.
По поводу производительности не хотелось бы делать голословных заявлений… А объективными тестами подкрепить не могу. Под задачу работы ведомственных сервисов Эльбрусы подходили полностью.kvant21
21.06.2016 01:43Спасибо за развернутый ответ.
Действительно, сценарий использования для отечественного крипто выглядит логично. С другой стороны, наверное всё же глобальный переезд на такую платформу — это не то же самое, что CentOS под Intel. Где и какая часть отвалится на незнакомом железе никто не скажет заранее. Грабли еще не собраны :) А на интеле можно и вовсе RHEL с поддержкой купить, там все грабли поименно знают. Но такой опыт с Эльбрусом был бы интересный, да…Landgraph
21.06.2016 08:48Нет, нет. RHEL нельзя. Нужно покупать МСВСферу за сильно дороже. Да ещё и всю жизнь платить за подписку на их репозиторий с RHEL'овскими пакетами. А иначе не будут выполняться требования ФСТЭК/ФСБ.
VitalKoshalew
21.06.2016 09:09Спасибо за статью, коллега!
«В качестве платформы виртуализации была закуплена — VMWare, на тот момент 5 версии. Тут, думаю, все согласятся, что выбор практически безальтернативен.»
Вот тут не соглашусь. В 2012 году не обязательно было тратить деньги на VMWare (у вас же на потолочный лоток денег не было!), когда можно было обойтись бесплатным Hyper-V Server (2008 R2, а к концу года и 2012), да и SCVMM тогда продавался отдельно от остального SC за относительно смешные деньги.Landgraph
21.06.2016 09:38Виртуальные машины от Microsoft на тот момент были сыроваты, того же режима Fault Tolerance не было. Изначально именно поэтому была выбрана vSphere. Сразу скажу, что после тестовых испытаний от работы в режиме Fault Tolerance пришлось отказаться. Те системы, которые были критичны — не могли работать на одном ядре. Хотя в одной из сопровождаемых организаций Hyper-V очень даже выручает, приятный бонус к лицензионной ОС.
Да и назвать его бесплатным язык не поворачивается. Даже при условии покупки Windows 2012 Datacenter с его безлимитными виртуальными лицензиями. Но если сравнивать, например, не версию Standard, а следующие версии — согласен, дешевле. И, опять же, если vSphere спокойно помещалась на USB-flash и отъедала всего ничего ресурсов, то Windows 2012 на хосте требовала для себя уже полноценной дисковой подсистемы в любом её виде, и других ресурсов отъедала побольше.
Вспоминаю свой эксперимент по выделению памяти. Если мне не изменяет память, то меньше чем с 1.5 Гб ОЗУ у меня 2012 винда даже не установилась: вылетала в синий экран. 2008 R2 требовала, порядка 1 Гб, 2003 ставилась и без проблем работала на 512. С одной стороны, конечно, не много. А с другой стороны 512 Мб ОЗУ — это нормальная такая виртуалка под Linux.VitalKoshalew
21.06.2016 18:05Мне хотелось бы услышать/прочитать описание хоть одного реального случая, когда FT сработал, как в рекламных брошюрах. Мне кажется, что вероятность того, что основной сервер так интересно выйдет из строя, что ни байта информации не будет повреждено до момента выхода, достаточно близка к 0. (Отключение питания в ЦОД маловероятно). Если данные всё же были повреждены, то вам не продолжать с ними работать надо, а срочно отменять все текущие транзакции, что и случится в случае падения обычной ноды кластера и *не* произойдёт «благодаря» FT. Поскольку вероятность повреждения данных >0, внедрение VMware FT, на мой взгляд, *ухудшает* этот самый fault tolerance.
Далее, если у вас критический сервис, минутный простой которого во время загрузки на другой ноде кластера недопустим, не имеет режима Active-Active, а запись на диск не имеет транзакционности, то что-то надо менять «в консерватории».
Ваш отказ от FT в итоге — ещё одно подтверждение того, что, как мне кажется, кроме редчайших случаев, технология FT — чисто маркетинговая, созданная для победы по формальному признаку в конкурсах/тендерах.
Что до цены, Вы, видимо, путаете бесплатный Microsoft Hyper-V Server и роль Hyper-V в Microsoft Windows Server. Это разные продукты с точки зрения покупки/лицензии. Hyper-V Server полностью бесплатен.
Лицензировать Windows на виртуальных машинах вам придётся вне зависимости от типа виртуализации, цена будет одна и та же для VMware и Hyper-V.
Поддержка/обновление системы на USB флешке где-то в недрах сервера, на мой вкус, это, скорее, минус. Загрузка с SAN в вашем случае была бы предпочтительней для любой системы виртуализации, мне кажется.
Заниматься подсчётом мегабайтов ОЗУ в системе виртуализации таких масштабов (5 лезвий с «ОЗУ под завязку 192Гб»), это, простите, демагогия. У вас и на последнем этапе написано «используя порядка 30-40% ресурсов ЦПУ и ОЗУ», не спас бы вас «лишний» 1ГБ на ноду.
Про «сыроваты» — это ваше личное «оценочное суждение», как сейчас модно говорить. В 2012 году вышла уже третья по счёту версия, полностью стабильная 2008R2 эксплуатировалась тогда уже 3 года в продакшене по всему миру (что для только появившегося рынка виртуализации — практически, вечность). ESXi вышла в том же 2008 году, что и Hyper-V Server. Предыдущие продукты виртуализации были у обеих компаний.
С учётом вашей же инициативы по переносу всего, что можно, на бесплатный Linux, «подсаживать» при этом всю систему на платный VMware на этапе её создания, мне кажется, противоречивое решение.
Я не настаиваю, что решение выбрать VMware было ошибкой, я лишь не согласен с тем, что оно было «безальтернативным».Landgraph
21.06.2016 19:50Спасибо за развёрнутый комментарий!
Постараюсь прокомментировать по пунктам:
1. На тестовом стенде Fault Tolerance я тестировал один из хардкорных вариантов: просто физически вынималось работающее лезвие, затем возвращалось. Понятно, что это не самый гуманный способ, но мне нужно было быть уверенным, что система не упадёт. И она не падала. Но это всё была «синтетика», как он себя поведёт в реальной системе — для меня тоже скорее вопрос, чем твёрдая уверенность. И мой мысленный эксперимент также не сулил ничего хорошего для FT.
Как показала практика, минутная пауза на старт системы для пользователей проходила не особо заметно. Все больше грешили на «отсутствие интернета».
2. Да, я имел в виду роль Hyper V.
3. С SAN была ещё одна очень «плавающая» проблема. До какой-то из версий прошивок контроллера, установленного в лезвиях, он сбоил и при перезагрузке не всегда видел назначенные ему LUN. Т.е. после загрузки гипервизора проблем я не помню, а вот на моменте так сказать инициализации BIOS — проблемы были. Это тоже было одним из факторов за перенос гипервизора на локальное хранилище.
4. Я не спорю, что не только VMWare занимались виртуализацией. У Microsoft виртуализация появилась ещё тогда, когда они приобрели Connectix Virtual PC, если мне не изменяет память. Также параллельно развивались VirtualBox, Parallels. Ну т.е. теоретически выбор был.
Но, повторюсь, одной из задач было поднятие FT. Маркетинг или нет — судить не хочу, но у одних FT был, у других нет, альтернативы по функционалу не было. И, в принципе, если бы не кривизна архитектуры ПО и возможность её горизонтально масштабировать — FT как минимум можно было бы запустить в бой. Также было ограничение по поддерживаем Hyper-V гостевым ОС, ESXi поддерживал большее количество гостевых ОС. Я вот сейчас точно не помню, но там было ещё какое-то ограничение на размер образа файловой системы, от которого VMWare избавилось раньше. Что-то было связано со значением в 2Тб, по-моему. Я так понимаю Вы более плотно работаете с Hyper-V, думаю Вы быстрее вспомните все различия того времени.
Доступно свежее сравнение гипервизоров, они идут практически ноздря в ноздрю, но т.к. у VMWare виртуализация — основной вид деятельность, мне кажется, что в частностях они слегка впереди. Но я боюсь, что это зарождается тема для холивара. В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.
5. По поводу «сырости» — Windows 2012 на тот момент только вышел. Если быть точнее, то на момент моего трудоустройства Windows 2012 только ещё планировался к выходу. Проблемы с ОС после выхода были и их было не мало.
Т.е. либо нужно было использовать заведомо устаревший гипервизор от 2008 R2, либо ждать и идти первым по граблям 2012…
6. В плане внедрения Вы меня несколько неправильно поняли. Инициатива появилась после трудоустройства. VMWare мне достался уже как факт на всех лезвиях. Когда приобретался Windows Datacenter — уже было понимание того, что какую-то часть лезвий целесообразно поднять на гипервизоре от Microsoft, хотя бы с точки зрения экономии на лицензиях гипервизоров. А под занавес работ и ESXi бесплатный появился.VitalKoshalew
21.06.2016 22:31Спасибо за интересное продолжение диалога!
Сразу оговорюсь, это не холивар, мне интересно сравнить впечатления и обменяться опытом. Я не «не люблю VMware» (как вы со смайликом написали в другом комментарии), я не вижу смысла его использовать при прочих равных, потому мне интересно услышать от тех, кто его всё-таки выбрал, о причинах — что я пропустил?
По пунктам:
1. Ну, то есть, фактически, вариант выключения питания. Да, красиво, на всех демо-стендах именно его и показывают. Практика, однако, даже моя личная, говорит скорее о возможности выхода из строя материнской платы, памяти, контроллера хранения с ненулевой вероятностью silent corruption данных в момент, предшествующий окончательному выходу из строя. В некоторых случаях приходится вообще откатывать данные из архива/снэпшота, при возможности, проводить ручную проверку, слияние последних данных и архивной копии и т.д. Продолжить выполнять задачу на другой ноде как ни в чём не бывало в таком случае — однозначное зло. Даже если мы примем, что вероятность «атомарной» поломки выше, чем пролонгированной с периодом silent corruption, вероятность последнего варианта ведь не 0. В таком случае, стоит очень хорошо подумать с точки зрения менеджмента рисков, что хуже — пару минут downtime или повышение вероятности повреждения данных.
Сразу прокомментирую и соседнюю ветку:
" Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же? "
Я уже писал выше — отказоустойчивость для важных систем должна достигаться на уровне приложения: active-active, транзакции, проверка целостности данных. Если этого нет, значит данные не такие уж и важные. Отказоустойчивость именно *нод* кластера — это подход pet (vs. cattle), он себя изжил, а в данном случае, с точки зрения менеджмента рисков — мы увеличиваем риски, внедряя VMware FT.
2. Так и Windows Server с ролью Hyper-V не требует покупки дополнительной лицензии, если у вас хоть одна виртуалка с Windows Server внутри лицензирована. Вас кто-то ввёл в заблуждение, нет за это оплаты и в таком случае. Есть платный SystemCenter, но это совсем другой продукт, виртуализация там — лишь один из компонентов.
3. Мне кажется, тут никаких вариантов кроме сесть на телефон и не слезать с гарантийной поддержки до полного исправления ситуации просто нет. Если прошивка контроллеров заведомо дефектная, ставить такие контроллеры в продакшен на основании того, что после загрузки они пока ни разу не глючили — неверно.
И, опять же, менеджмент рисков говорит, что нода, которая не загрузилась (она не под нагрузкой, есть ещё 4 других и вторая площадка) представляет меньшую опасность, чем внезапное повреждение системного раздела под полной нагрузкой и, в лучшем случае, выход из строя ноды в случайный момент (вероятно, под нагрузкой), а в худшем — опять же, повреждением данных.
4. Про FT — выше. Как инженер, мне кажется, вы должны были не только в FUD-таблички вроде этой смотреть. В ней, между прочим, к каждой второй строчке надо добавить сноску, плюс там нет ни одной строчки с функциональностью, которая лучше в Hyper-V (если совсем нельзя было пропустить, сделана обобщающая строчка, а в ней через запятую указана в том числе киллер-фича Hyper-V, так что и непонятно, это вообще плюс, минус или просто другое название).
И вы, простите, продолжаете, верю что неосознанно, идти по методичке. Следующий стандартный пункт — «поддержка ОС». «Free as in 'free beer' or in 'free speech'?». Слово «поддержка» с точки зрения Microsoft: вы можете открыть тикет в поддержке Microsoft, и вам окажут квалифицированную поддержку, плюс имеется договор с производителем ОС. Слово поддержка с точки зрения VMware: «мы смогли это запустить». Особенно радует «поддержка» древних систем, которые не поддерживает сам производитель (тот же Microsoft, например).
Поддержка образов больше 2TB появилась в Hyper-V в 2012, а в ESXi — в 2013. Вы, определённо, читаете какие-то специфические ресурсы, раз даже это вам запомнилось как победа VMware. :)
«В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.»
Ну вот я на протяжении всего этого разговора хочу услышать что-то индивидуальное. Пока, к сожалению — только стандартный список FUD (уж простите!) и, скорее, вредных «фич», слышанный мной с десяток раз от продавцов VMware.
5. «Проблемы с ОС после выхода были и их было не мало.»
Ну это совсем FUD — даже без примеров. У любого софта есть некоторые проблемы, для того и выходят постоянно обновления. Плюс Hyper-V Server имеет малый footprint, позволяющий значительно снизить количество обновлений, которые нужно применять, по сравнению с Windows Server с полным интерфейсом и другими ролями.
Что «заведомо устаревшего» в 2008R2? В 2012 появились новые возможности, но Hyper-V 2008R2 до сих пор делает своё дело в консервативных компаниях и проблем никаких нет — поддержка до 2020 года, если я правильно помню, будет длиться. Никто не мешает производить обновление по мере выхода новых версий — это не платный продукт, который нужно каждый раз заново покупать.
ESXi 5.0 был тогда тоже «заведомо устаревший», ведь в конце года вышел 5.1…
6. Ну в статье у вас написано немного по-другому. Если досталась в наследство — ну досталась так досталась. Я думал, была какая-то объективная причина выбора.
Что касается «Windows Server Datacenter» — тут у вас (и у авторов таблички с vmwarearena, на которую вы ссылаетесь) какое-то странное смешение понятий — тип лицензирования виртуальных машин с Windows Server вообще никак не влияет на лицензирование Hyper-V (оно бесплатно). Платный продукт — SystemCenter, с ним и надо сравнивать VMware vSphere 6 Enterprise Plus (желательно — со всеми компонентами SC: мониторинг, автоматизация, резервное копирование, контроль конфигурации).
Про бесплатный ESXi — там же даже HA нет, каким образом он применим в описанной архитектуре?kvant21
22.06.2016 02:10Вот я тоже могу рассказать, почему выбирают vmware.
1) Жесткий HCL vs «заведется любая железка, под которую есть драйвер для Win, но грабли ищите сами». Это не значит что на vmware не бывает проблем из-за кривых драйверов, но по меньшей мере, дает какую-то опорную точку для подбора железа. Да и вендоры охотнее проблемы решают, когда их строчка в HCL под угрозой.
2) Patch tuesday на хостах виртуализации каждый месяц, а современные ESXi спокойно работают годами, только и нужно, что следить за серьезными security-заплатками, которых, по-моему, и не было со времен Heartbleed.( и то это только management-интерфейсов касалось.)
3) SCVMM глюкавый и неудобный, и даже меееедленный веб-клиент vsphere в использовании приятнее. По-крайней мере он всё в одну точку сводит, а не так что «это у нас в SCVMM, а за вот тем пожалуйте в cluster manager». Скажете, это личные предпочтения? Найдите хоть одного человека, который в восхищении от SCVMM после vCenter.
4) MS premier support стоит космических денег, поэтому в большинстве случаев конечные пользователи остаются один на один с технетом.
5) В мире vmware по-прежнему основной гипервизор в энтерпрайзе, поэтому иногда hyper-v просто не поддерживают. Есть у нужного веднора только virtual appliance в виде OVF, и всё.
6) Сопутствующие vmware-only технологии, например vSAN и NSX. Знаю, S2D грядет, но пока это будущее.
7) В целом архитектурно vmware красивее. Например, зависимость работы кластера от наличия живого домена — довольно неожиданное ограничение Hyper-V. Всякие disaster сценарии не упрощает. Хотя, что до красоты, внутреннее устройство vcenter или его appliance — тот еще дремучий лес. Но, по-крайней мере, сам ESXi очень лаконичный.
В общем, моё мнение — vmware более цельное и интегрированное решение, система «сама в себе», а hyper-v несет в себе много чисто виндовых запчастей, которые скорее мешают, чем помогают.
При всём при этом ценник на взрослые версии vmware термоядерный, и у них есть ненулевая вероятность лет через пять стать чем-то вроде Oracle DB — вроде бы круто, но мало кто толком объяснит почему, и уж точно вряд ли сможет обосновать стоимость против аналогов. Зато SAP поддерживает! Короче, для больших неповоротливых махровых компаний.
А hyper-v поделят с KVM остальной рынок :)
Хотя, с введением per-core licensing в WS2016 и возвращением функциональных отличий в редакциях всё может вдруг стать не так однозначно…
P.S. А вот с FUDом по поводу нежелания переводить рабочие системы резко на новейший Win Server вы точно погорячились. Кто в здравом уме будет грабли собирать на боевых нагрузках? Тем более, когда речь об ОС — в этом случае и железо тоже должно быть совместимо. А вендоры еще не собрали баги в новых драйверах… Чур меня, чур! Год минимум от релиза. В лабе погонять — другое дело конечно, там и с technical preview начинать можно.
Вот vmware кстати как раз уже год всем демонстрируют с ESXi 6, что проблемных релизов можно ожидать от кого угодно.VitalKoshalew
22.06.2016 04:45Не удержусь, прокомментирую по пунктам, хоть, простите, в отличие от автора статьи, ваше сообщение — уже на грани холивара.
1. «Отсутствие драйверов — это благо!», «Мир — это война!», «Свобода — это рабство!»…
2. Отказ от установки обновлений как-то странно обсуждать даже. Ваше право, но это уже давно плохая практика. Даже если своего понимания нет, почему так не стоит делать, аудиторы не дадут. Для чего в кластере cattle молиться на аптайм — не представляю. Cluster-aware update те немногие обновления, которые нужны Hyper-V, заливает сам по очереди на все ноды.
3. Эффект утёнка? Стандартный стиль mmc, всё в общей парадигме Windows Server management.
4. Windows Server SA (который, по хорошему, и так должен быть у всех, при наличии виртуальных машин с Windows Server) даёт право на поддержку, не premier, но и не Technet. Premier это, по сути, замена штатной единице, стоит соответственно. Покупать ли поддержку у Microsoft — ваш выбор. Пользователей VMware никто не спрашивает.
5. Можно статистику в качестве пруфа или пояснение термина «основной»? OVF вообще как бы независимый стандарт для обмена, MVMC его импортирует.
6. С vSAN соглашусь — свою специфическую нишу решение имеет. S2D, действительно, выйдет через пару месяцев.
Что до NSX, я, может, что-то пропустил, но vCloud Networking and Security (ныне NSX) догнал SCVMM 2012 SP1 (в котором уже была технология SDN) только в 2013 году. Это не то что не «VMware-only технология», тут VMware в догоняющих. Более того, при цене одной лишь NSX, насколько я знаю, «от $5k за процессор», нужно ещё поискать того, кто её в здравом уме купит.
7. Насколько «красивее» чужеродная в среде Windows-серверов технология «сама-в-себе» лучше спросить у стандартного Windows-админа, которому вместо привычных систем достаётся в наследство такое чудо. Вон ниже в треде человек перепутал HA и FT, и немудрено.
Представлять же благом отсутствие интеграции с централизованной аутентификацией, менеджментом и мониторингом (для которых, внезапно, необходимы сервера аутентификации AD), замена привычных средств (mmc, WMI, PowerShell и т.д.) самоделками — это продолжение вашего пункта 1: «Любовь — это ненависть!»
«Хотя, с введением per-core licensing в WS2016 и возвращением функциональных отличий в редакциях всё может вдруг стать не так однозначно…»
Почему все VMware-админы приплетают к Hyper-V лицензирование Windows Server (как будто в середе VMware можно их не лицензировать!), для меня загадка. Видимо, все VMware-ресурсы друг у друга таблички перерисовывают без понимания, а вы потом их читаете, не разбираясь. Повторю ещё раз: Hyper-V — бесплатный гипервизор.
«P.S. А вот с FUDом по поводу нежелания переводить рабочие системы резко на новейший Win Server вы точно погорячились.»
Простите, вы перевираете. FUD-ом я назвал FUD про «проблемы ОС».
«Кто в здравом уме будет грабли собирать на боевых нагрузках? Тем более, когда речь об ОС — в этом случае и железо тоже должно быть совместимо. А вендоры еще не собрали баги в новых драйверах… Чур меня, чур! Год минимум от релиза. В лабе погонять — другое дело конечно, там и с technical preview начинать можно.»
Я так и написал — хотите консервативный подход — был (в 2012) Hyper-V Server 2008R2, который уже 3 года был в продакшене. Когда дозреете для апгрейда — гипервизор бесплатный, покупать новую версию не надо.
А если «год минимум до релиза», то автору нельзя было и ESXi 5.0 ставить — ей тогда года не было.
Предлагаю отойти от риторики холиваров и, если хотите, продолжить более предметно, а не «нравится — не нравится».
Из всех ваших пунктов я себе на заметку могу взять лишь vSAN. В условиях миниатюризации и всё большей специализации вычислительных нод я не уверен, что за гиперконвергентностью светлое будущее, но согласен, что наличие функциональности — это плюс. Для кого-то, возможно, это станет решающим фактором. Через несколько месяцев и в этом вопросе будет достигнут паритет.Landgraph
22.06.2016 10:49Для продолжения дискуссии хотелось бы для себя кое-что уяснить, и внести правку:
1. Коллега, Вы имеете опыт боевого использования обеих систем виртуализации?
2. У меня имеется опыт использования в бою только VMWare, VirtualBox — дома. На Hyper-V у меня только в одной организации работает одинокая FreeBSD, поэтому я это опытом не считаю.
Сейчас я понимаю, что вызвал бурную реакция словом «безальтернативен», прошу прощения. Я несколько изменил формулировку, чтобы она больше соответствовала действительности.
У меня складывается впечатление, что Вы имеете большой опыт развёртывания систем на базе решения Windows. Либо, если есть опыт работы с обеими системами виртуализации, то тут уж я бы лучше Вас послушал на тему чем одна из них лучше, чем другая.
Я честно скажу, объективно сравнить две системы не могу. Да, я хотел использовать в ЦОД и ту и другую виртуализацию, чтобы можно было в т.ч. объективно рассуждать, но не успел.
По своим субъективным ощущениям, если опустить маркетинговые сравнения, мне VMWare нравится больше потому, что она на Linux. Что мне, в первую очередь, не нравится в Hyper-V? Windows Core.
Нет, я не злобный линуксоид, у меня даже есть сертификаты, что я самый что ни на есть сертифицированный Windows-админ. У меня достаточно большой опыт внедрения и эксплуатации различных систем на различных операционных системах. Я ненавижу настраивать Linux: пока настроишь с ума сойдешь. Но когда всё настроил — он ведёт себя очень предсказуемо. Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.
Обновления в обеих ОС — это вообще отдельная песнь льда и пламени: практически в каждой серии или кого-то убьют, или будет секс.
Но давайте не забывать, что и одно и другое — всего лишь инструменты. Поэтому для каждой ситуации решение должно выбираться индивидуально, а не только потому, что «раз я это знаю, значит этим и надо пользоваться». Хотя часто бывает, что и эта причина ставится во главу угла: смысл специалиста по windows заставлять сопровождать *nix и наоборот? если уж в компании есть хороший windows-админ, то лучше ему давать те инструменты, которыми он владеет в совершенстве, а не подставлять и потом говорить «тыжпрограммист!», когда что-то упало.
Лично мне на тот момент и сейчас было бы абсолютно всё равно на чём поднимать виртуализацию: VMWare или Hyper-V. У заказчика-работодателя был на тот момент приобретён VMWare, его нужно было заставить работать, я это и сделал. Если бы системы виртуализации не было — выбор, ввиду долгих конкурсных процедур и т.п., однозначно пал бы на любое бесплатное решение, но и тут выбор был бы необъективен, а навязан финансово-временными рамками.
Если бы у меня действительно была возможность выбирать, я бы пошёл по пути снижения вероятности выхода из строя по причине виртуализации и внедрил бы сразу две системы виртуализации (всё равно какие, лишь бы две, максимально непохожие друг на друга). И разделил бы резервируемые сервисы между ними (например, основной и резервный контроллеры домена). Чтобы если уж вдруг, в какой-то момент времени произойдёт какая-то неисправность (ошибка программиста ВМ, внешняя атака, ошибка администратора...) в одной системе виртуализации — вторая осталась работать. Но это, мне кажется, идеальный случай.VitalKoshalew
27.06.2016 05:51Прошу прощения за задержку с ответом.
Решения на базе Hyper-V я внедряю где-то с конца 2009 года, то есть примерно с выхода 2008R2. С VMware ESX/ESXi работал с версиями 2-4. Как я уже писал, со времён выхода Hyper-V 2008R2 я не вижу смысла при прочих равных в использовании VMware, потому и задаю вопросы тем, кто остался на VMware, как оно там.
«Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.»
Или я вас неправильно понимаю, или вы неправильно «готовите» Windows Server: для того и существуют GPO, SCCfgMgr и прочие Desired State Configuration, чтобы по возможности никогда не лезть в настройки продакшена руками. В крайнем случае, идёт запись всех действий в систему контроля изменений с последующим превращением записи в CMS в пошаговую инструкцию. Искать каждый раз галочку, это, конечно, олдскульно, но, мне кажется, так давно не стоит делать.
Что до поддержки двух систем в одной организации, это мне кажется странной идеей: правильное разделение основных и резервных мощностей, production и staging требует как раз унификации, а не различия между платформами. В то же время, поддержка двух платформ в дополнение ко всем вышеперечисленным разделам приведёт к дикому раздутию штата и бюджета IT, а на дворе кризис, бизнес впервые начал считать деньги. И, главное, я не вижу как именно фирма-поставщик виртуализации (не, скажем, одновременное обновление, а именно марка системы) может быть той SPoF, которой следует избегать любой ценой.
kvant21
22.06.2016 13:18Не холивара ради, а истины для:
1) Не совсем так, проблема в отсутствии HCL, а не в наличии драйвера. HCL — подмножество всего железа, имеющего драйверы.
2) Не спорю, но возможны разные сценарии. Сетевые свитчи, например, никто не обновляет каждый месяц, хотя там тоже и кластеры, и rolling upgrade, и все такое — изменения могут внести проблемы, а зачем это нужно, если и так всё хорошо? Обновления ради обновлений — не совсем правильный подход, по-моему.
3) Не во фломастерах ведь дело, а в том, что hyper-v manager, FCL manager и SCVMM имеют непересекающиеся функции, и работать приходится со всеми тремя. И это шаг назад после vcenter, как минимум.
4) SA support совсем грустный по моему опыту — продраться сквозь начальных индусов к инженерам — подвиг. И телефонной поддержки нет. Но согласен, выбор это лучше, чем его отсутствие.
5) Нет, к сожалению, статистики нет, это мой личный опыт. Как пример — почти всё что делает Cisco, не поддерживает Hyper-V. Обратные примеры мне не попадались. Можете сказать что личный опыт — это не аргумент, но мы же начинали с вопроса, «почему кто-то покупает vmware?», а не «кто сильнее, слон или кит?».
6) Сразу скажу, я не щупал NSX, но насколько я это понимаю, то что есть в SCVMM ближе к vDS, и куда проще. Не просто так они столько денег за NSX просят.
7) Холиварный пункт, не хочу развивать. Мне кажется, виртуализация слишком специфическая, чтобы сильно выигрывать от интеграции с экосистемой, вам так не кажется. Давайте останемся «при своих».
Да, лицензирование Win Server — отдельная история от гипервизора, я знаю. Вот как сравнивать с vmware, так всё бесплатно, а как поддержка, так везде Software Assurance должна быть! :)
А вообще просто лично меня задели сильно эти изменения, простите, не удержался. Кстати, S2D будет только в старшей редакции.
Поймите правильно, я просто предлагаю взгляд со стороны. И хочу сказать, что и за vmware, и за Hyper-V есть аргументы. Иначе, наверное, vmware бы уже прекратила существование.VitalKoshalew
27.06.2016 07:28И у вас прошу прощения за задержку с ответом.
1. Собственно, драйвера без подписи WHQL, и, соответственно, без тестирования WHC просто нельзя установить на 64-битных Windows Server. Я понимаю, что вы хотите сказать, но, мне кажется, что это из разряда «зелен виноград».
2. Вы можете для себя, конечно, устанавливать сколь угодно мягкие рамки, но стандарты индустрии, например, §6.2 PCI DSS требуют установки обновлений безопасности на критические системы максимум в течение месяца, на остальные — трёх. Коммутаторы и прочее сетевое оборудование входит в список систем, подлежащих обновлению. Даже если вашей компании не требуется формальная сертификация, прислушиваться к стандартам, мне кажется, всё равно стоит.
3. Если задача — работать строго с системой виртуализации, не пересекаясь ни с какими другими подсистемами, специализируясь только в этой узкой области, изучая только её, то, возможно, одна программа-агрегатор удобнее. Если же виртуализация — просто ещё один инструмент в руках системного администратора, то чем повторять в отдельной консоли все функции, которые уже есть в других, имеет смысл просто добавить недостающие. Hyper-V — всего лишь ещё одна роль Windows Server, SCVMM — ещё один компонент SC.
Более того, решение задач настройки Windows Server всё больше дрейфует в сторону единой консоли, имя которой — PowerShell.
5. Ок, принимаю к сведению ваши наблюдения. Единственное, я не уверен, что вы не путаете поставку в виде универсального OVF с отсутствием поддержки/невозможностью запуска под Hyper-V. Приведу пример: OSSIM. Формально (как минимум раньше, сейчас может уже записали «поддержку»), был ISO образ для установки на голое железо или на VMware. Реально — всё работало под Hyper-V даже со старым ядром, включая анализ копии сетевого трафика. Поддержки в смысле службы поддержки нет ни под VMware ни под Hyper-V — OpenSource.
6. Я не разделяю ваше понимание, HNV — полная виртуализация, всё заворачивается в NVGRE (а в новой версии, и, опционально, в VXLAN). За что VMware просит столько денег при наличии конкурирующих бесплатных (или более дешёвых, в случае SCVMM) решений — мне лично непонятно.
«А вообще просто лично меня задели сильно эти изменения, простите, не удержался. Кстати, S2D будет только в старшей редакции.»
Я тоже не в восторге от этого изменения политики лицензирования Windows, но эта проблема одинаково коснётся пользователей всех систем виртуализации. Что до S2D, я поначалу тоже стал проклинать маркетологов, но потом подумал, что при реальном внедрении там и так уже будет Datacenter для виртуальных машин в большинстве случаев. Хотя, всё равно обидно, да.
«И хочу сказать, что и за vmware, и за Hyper-V есть аргументы. Иначе, наверное, vmware бы уже прекратила существование.»
В наш век маркетинга как раз более продвинутые, на мой взгляд, BlackBerry OS 10 и Windows на мобильниках прекращают своё существование, а покупатели стоят в очередях за очередным iPhone и Galaxy S7.
У VMware более удачная политика продвижения, они на рынке дольше и у всех на слуху, как ксерокс фирмы Xerox. Немалую роль играет и, в моём понимании, не очень честный подход со стороны сертифицированных VMware системных администраторов: они вложили немалые деньги в своё обучение и сертификацию, плюс боятся конкуренции с обычными администраторами Windows, так как никаких arcane знаний администрирование Hyper-V не требует. Поскольку начальство/заказчик всё равно не могут сделать осознанный выбор, решение использовать ту или иную платформу полностью отдаётся на откуп системным администраторам, а те необъективны в своём выборе, и, для сохранения своих инвестиций и защиты рабочего места, покупают (на деньги заказчика/работодателя!) дорогостоящую систему от VMware при наличии однозначно не худшей бесплатной альтернативы от Microsoft.
Я также читал, что VMware платит интеграторам просто за факт предложения VMware в новых проектах, но это, возможно, FUD — не поручусь.
Пока я насобирал следующий список преимуществ (без кавычек) VMware:
— vSAN (хотелось бы ещё увидеть статистику реальных внедрений, ведь необходимо совсем другое оборудование, чем для классической виртуализации), который появился относительно недавно и через пару месяцев получит конкурента в виде S2D.
— Какие-то проприетарные виртуальные appliances. Опять же — совсем нишевый случай.
То есть абсолютное большинство инсталляций VMware последних лет не имели под собой никакого фактического обоснования.kvant21
29.06.2016 20:431. Согласен, есть WHC. Тем не менее, я считаю, что Windows может выполнять столько разных функций, что на совместимость именно с Hyper-V у ведоров упор значительно меньше. Можно, конечно, сказать, что зато и пользователей каких-нибудь сетевых драйверов на Windows гораздо больше и баги выявятся раньше…
И всё же, HCL именно для Hyper-V был бы плюсом.
2. Я к числу авторов PCI DSS не отношусь, поэтому спорить со стандартом не буду. Тем не менее, стандарты пишутся так, чтобы охватить (и в данном случае защитить) большое количество самых разных окружений, поэтому в частном случае требования могут быть избыточны. Я считаю, что при должной оценке рисков можно и нужно строить безопасность так, как этого требует конкретная ситуация. Впрочем, против compliance не попрешь, но это не у всех.
Как бы то ни было, патчей у vmware выходит в разы меньше, и еще меньше относится к безопасности.
3. Нет, но консоли-то у Hyper-V три! И все относятся только к виртуализации, кроме, разве что, FCM.
Powershell — согласен, сам большой поклонник MSовского подхода к CLI.
У vmware, кстати, тоже powerCLI есть, хотя лично мне и не всё нравится, как там организовано.
5. Ну вот, например: «VMware vSphere ESXi is mandatory for all virtualized deployments of Cisco Collaboration.» То есть даже если и удастся запустить CUCM на другом гипервизоре, поддержка помашет ручкой.
Касательно маркетинга — я соглашусь, vmware во многом сильна именно им. Пункт 5 относится туда же, кстати.
Но вот насчет того, что Hyper-V не требует подготовки в отличие от vmware я ну никак согласиться не могу.
На базовом уровне и то и то влёт осваивается до состояния «сервер с парой работающих виртуалок». Hyper-V, пожалуй, на полшага проще, т.к. поставить Win Server уже понятно как, роль в списке уже есть, а оснастка и модуль powershell входят в RSAT.
Вместе с тем, установка vmware сводится к загрузке с ISO и ответу на пяток вопросов вида «на какой раздел будем ставить» и «введите пароль администратора». После этого сетевые настройки прямо перед носом, клиент для управления качается при попытке зайти на ip-адрес новоявленного ESXi хоста, и дальше создать и запустить ВМ ну никак не сложнее чем в Hyper-V.
Что же касается более сложных задач, то и к Hyper-V, и к vmware подходить без специфических знаний будет очень нелегко, и для работающего окружения — попросту опасно. Потому что нужно понимать, как виртуализация работает, а не запоминать где какая кнопка. И ну никак в этом случае тот факт, что оснастка VMM входит в уже знакомые RSAT, не релевантен.
В моём понимании, как и с Windows Phone (ну не настолько, конечно), Hyper-V не хватает не столько технических возможностей, сколько поддержки рынка. Это тот самый пункт 5. А еще это куча статей и прочего fan fiction от посторонних специалистов, такого как исследования производительности, гайды а-ля «точечная настройка хоста для realtime приложений», готовые ответы на вопрос «Ошибка 0x0000BAD, что делать?», и полчища индусов в саппорте самых разных вендоров железа и софта, которые знают ответ на 10 вопросов по Hyper-V и на 100 по vmware, просто в силу того, что их задают чаще.
Как я уже сказал, в данный момент vmware сами себя загоняют в угол с помощью ценовой политики, но если ситуация хоть немного выравняется, MS понадобятся очень убедительные технические доводы в свою пользу помимо «у нас всё то же самое но несколько дешевле», чтобы развернуть неповоротливый рынок. Кстати, против KVM они бы тоже пригодились.
sharkirill
21.06.2016 09:42Не место красит человека, а скромность красит человека!
П.С. За решение установить USB-flash с образом VMWare отдельное спасибо, когда флешки стали дохнуть по очереди и отваливаться лезвия мы Вас вспоминали)Landgraph
21.06.2016 09:51Всегда пожалуйста =)
Я так понимаю Вы — сотрудник, пришедший уже сильно после меня? Могу Вам рассказать секрет. Изначально планировалось использовать промышленную Flash-память, но денег на неё не было (и не смотрите так на меня, я помню те времена, когда у нас было оборудования на много миллионов рублей, а оптических патч-кордов чтобы его соединить я ждал 2 месяца), поэтому пришлось устанавливать бытовые накопители. Срок службы бытового накопителя — ограничен. Поэтому планировалось делать ПЛАНОВУЮ замену не реже, чем раз в 1.5 года, либо планово перейти на промышленную память.
Боюсь спросить, что случилось раньше: плановая замена или они вышли из строя, а потом была внеплановая замена? =)
У нас и жёсткие диски в полках отказывали (кстати на одном из фото в статье виден отказавший жёсткий диск в одной из полок), за что, я надеюсь, вы мне тоже благодарны? =)sharkirill
21.06.2016 11:26Да только жесткие диски были собраны в RAID и отказ одного диска в полке это штатная ситуация. А USB-flash (бытовая) единственная!!! (на лезвие) установленная в единственный USB-разъем лезвия это уже проблема.
Но если мы вернемся в IBM Redbook вышеописанному http://public.dhe.ibm.com/systems/support/system_x_pdf/00d9283.pdf стр.43 то USB-разъем должен использоваться для установки “USB Flash Key”.Landgraph
21.06.2016 11:54Спасибо за комментарий!
Лезвия были собраны в отказоустойчивый кластер. Ваш ответ я понимаю так, что плановая замена не была выполнена, вследствие чего выход из строя был неприятным сюрпризом. К моменту моего ухода как минимум часть накопителей работала уже почти год, соответственно их нужно было менять. Я сожалею, что вы попали в такую ситуацию, но не считаю не выполнение плановых мероприятий ошибкой архитектора.
Коллега, Вы перевели «USB Flash Key» дословно, а это не совсем корректно и из-за этого у Вас случилось недопонимание. Не я первый придумал установить гипервизор на USB, и IBM разделяет со мной мысль об установке гипервизора на «USB память ключ». И даже предлагает «ключи» с предустановленным гипервизором за деньги. Прошу прощения, если мы с IBM оказались не правы.sharkirill
21.06.2016 12:23А каким способом был реализован отказоустойчивый кластер, если вы говорите выше что «Сразу скажу, что после тестовых испытаний от работы в режиме Fault Tolerance пришлось отказаться. Те системы, которые были критичны — не могли работать на одном ядре.»?
Landgraph
21.06.2016 12:29VitalKoshalew
21.06.2016 19:01Добавлю ещё один аргумент против VMware — необходимо, чтобы ваши приемники тоже хорошо знали VMware. Как видите, это не всегда возможно, особенно с учётом специфики гос. предприятий. Вероятность того, что приемники будут разбираться в Windows Server, значительно выше.
Landgraph
21.06.2016 20:38Полностью согласен. Обычно именно по этой причине стараюсь делать выбор в пользу Windows-решений. Всё-таки они более user friendly…
Но тут-то я делал систему что называется «для себя», а меня вмварью не запугать =)
Я вообще рассчитывал задержаться в этой организации, т.к. нереализованных идей была масса…
kvant21
22.06.2016 02:35А я вот не очень согласен. Главное понимать как оно на самом деле работает — почему снэпшот не бэкап, почему кластер — это не значит что у вас никогда ничего не сломается, что будет если LUN отвалится на хранилище во время работы ВМ, ну и прочее. И тут навыки настройки файлового сервера на Win или администрирования AD мало чем помогут.
Лучше уж пусть не думают что «разбираются»… А так что vmware, что hyper-v — тоже GUI, тоже все подписано, и тоже вся документация под рукой.VitalKoshalew
22.06.2016 05:52Навыки настройки файлового сервера помогут самым прямым образом — вместо всех этих LUN, если нет унаследованного SAN, сейчас (года с 2012-2013) имеет смысл развёртывать SoFS (тот самый «файловый сервер на Win») с SMB3 для хранения виртуалок. Multipath, bandwidth trunking, всё в лучшем виде. (Кстати, в ESXi поддержка NFS 4.1, насколько я знаю, появилась год назад и с такой кучей ограничений, что даже фанаты плюются).
И навыки администрирования AD/GPO пригодятся, и PowerShell, и mmc, и подсистема Event-ов, включая возможность централизованного сбора, и Failover Cluster Manager, и Windows Firewall с IPSEC, и Performance Monitor и другие средства мониторинга — это просто Windows Server с полутора ролями. Человек со знанием Windows Server сможет администрировать Hyper-V сервера значительно за пределами «GUI, где всё подписано».
khanid
22.06.2016 09:53А вот здесь я не соглашусь.
Вероятность того, что приемники будут разбираться в Windows Server, значительно выше.
Это уже скорее исторически сложившийся миф, когда порог вхождения в win был много ниже, чем в *nix.
Тот же HA кластер на винде не сильно прощем vmware'ного, а местами может даже и сложнее из-за некоторых неявных вещей, так что в случае возникновения проблем у приемника может оказаться много больше головной боли, чем если бы это был vmware.
Как сказали выше, обычные навыки " я умею в файловые шары и поставить ад на виртуалке" тут не помогут.
Документации сейчас немало для освоения, поэтому в автральном режиме, когда что-то упало, тратить время на ознакомление с ней — это достаточно непрофессионально.Landgraph
22.06.2016 11:22Коллеги, мне кажется, вы спорите о различных специалистах. Оставим на минуту то, что написано в дипломе и условно разделим специалистов на техников и инженеров.
Коллега прав, техника с поверхностным знанием Windows найти гораздо проще, чем со знанием Linux. Но и другой коллега прав, техник вполне успешно может совершать 90% работы по обслуживанию той или иной системы: он «знает» (скорее помнит), где нужно поставить галочку, какой провод выдернуть/вставить, на какую кнопку нажать, какой узел «планово» перезагрузить, «сделать файловую шару»,«поставить ад на виртуалке» и т.д., на этом моменте его и начинают путать с инженером.
Инженер же обладает глубинными познаниями о том КАК работают те или иные технологии. Инженер может не знать какую именно галочку нужно поставить в Windows, или какую команду выполнить в Linux, или что написать на оборудовании Cisco, чтобы обеспечить физическое резервирование и увеличение пропускной способности. Как оно будет называться (nic teaming, bonding, lacp...) — не важно, он знает КАК работает эта технология, поэтому уже через пару минут чтения документации «по ключевым словам» он уже втыкает провода в циску и, тихонько ругаясь, что-то непонятное пишет сначала в одной консоли, затем в другой.
Поэтому поднимать HA-кластер, планировать структуру AD, разворачивать сеть и т.д. должен специалист уровня инженер, лучше — системный инженер (т.к. он видит более общую картину). Техник же тоже может без особых проблем поднять кластер HA: по инструкции (вероятнее всего написанной инженером). И всем будет казаться: зачем нужен высокооплачиваемый инженер, если есть низкооплачиваемые «инженеры», которые делают то же самое.
И на этом моменте не надо путать смену одного инженера другим и смену инженера бюджетным «инженером»-техником.VitalKoshalew
27.06.2016 07:48Вы правильно описали универсального (пост-)советского инженера. Мне кажется, такие специалисты достаточно редки даже в ваших краях, не говоря уже о моей стороне глобуса, где предпочитают специализацию. Они ценны на этапе проектирования и создания инфраструктуры, но на этапе поддержки и планового развития в них уже нет необходимости. Такие специалисты достаточно дороги, чтобы держать их просто для поддержки, если вы не интегратор. Вот тут на сцену и выходит условный младший инженер в пост-советской терминологии (или Server technician/associate, не путать с Desktop technician, который как раз техник). В общем, не важно как он называется, но вероятность того, что он сможет, скажем, посмотреть Events на Hyper-V сервере, достаточно высока, а для VMware уже нужно нанимать специалиста по VMware.
VitalKoshalew
21.06.2016 19:47Ещё раз по поводу загрузки с USB. Дело в том, что такая возможность в Hyper-V Server (не помню точно, возможно, только с версии 2012) была, но Microsoft намеренно запретила самостоятельную установку на (бытовые) флешки. Образы для загрузки с USB были доступны только OEM-партнёрам при условии тестирования и гарантии надежности накопителя.
Сейчас, в основном, от этого даже OEM отказались в пользу SATA DOM, которые втыкаются прямо в разъём на материнской плате и собираются в стандартный RAID1 силами SATA-контроллера.
Если можно, вопрос: блейд-системы IBM уже были до вас. Поскольку дисков в самих лезвиях не было, как производилась загрузка — с SAN? По какой причине было принято решение отказаться от штатного режима загрузки и использовать вместо отказоустойчивой SAN бытовые USB флешки?
Я почему спрашиваю: не примите на свой счёт, просто вы перечислили все «selling points» VMware vs. Hyper-V из методички продавцов VMware. С вами, случайно, поставщик решений VMware не общался на этапе принятия решений? Я не намекаю ни на какую коррупцию, я имею в виду, не ввели ли вас в заблуждение, выдав спорные, но уникальные для VMware возможности за новейшие прогрессивные технологии, которые вы и попытались внедрить?Landgraph
21.06.2016 20:27Да, загрузка производилась с SAN, но с ней были проблемы, в т.ч. программно-аппаратные. Плюс это дало разделение выполнения и данных, что упростило и ускорило процесс поиска неисправностей.
Обладай я неограниченным ресурсом, стал бы я снова ставить гипервизор на флешки? Не думаю. Стал бы смешивать исполнение и данные? Не хотелось бы, но ситуации бывают разные.
Нет, со мной поставщики решений VMWare не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?
Landgraph
21.06.2016 20:48Я понял! Вы просто не любите VMWare! =)
Так это же просто инструмент! Здесь он был применён из-за возможностей Fault Tolerance. То, что желаемое разошлось с действительностью — проблема скорее архитектуры приложения, чем VMWare. Но при некоторой доработке архитектуры приложения напильником его всё-таки можно использовать. А аналога у Hyper-V по-прежнему нет =)
kolu4iy
110. Кросс.
Помню, как в 2010 или 11 мы его выламывали и заменяли на бюджетные панели RJ45, потому что уже наелись…
Landgraph
Свои мучения со 110 кроссом я вспоминаю с ужасом. В данной конкретной ситуации, я уверен, это была просто потеря времени. Имело бы хоть какой-то смысл ставить кросс при необходимости нарастить длину. Но руководство хотело чтобы дёшево и универсально. Дешевле и в наличии в городе больше ничего не было.