Поскольку Cloud4Y активно работает с крупным бизнесом, то и проекты у провайдера часто крупные и сложные. И часто процесс миграции в облако затягивается не из-за трудности внедрения тех или иных облачных решений, а из-за разнообразных бюрократических препон и многоуровневых согласований. Ещё один нюанс — NDA. Мы не имеем права нарушать коммерческую тайну и NDA, а потому зачастую не можем рассказать про множество интересных (смешных и не очень) историй. Хотя их за более чем 12-летнюю историю компании накопилось много.
Но кое-что сквозь юридические завесы всё же просачивается. И сегодня мы расскажем об одном интересном проекте. Юристы и безопасники вычистили из этой истории всё, что могло бы помочь идентифицировать клиента или раскрыть его бизнес-секреты. Но в целом удалось сохранить смысл.
Итак, рассказываем про то, как крупная российская компания переносила свои сервера в облако Cloud4Y.
Предыстория
Работала на территории России Очень Большая Компания. Так её и назовём, ОБК. Она активно развивалась и была известна многим людям, на продукцию был активный спрос. Руководители были толковыми, исполнители — компетентными. Поэтому ОБК росла и процветала.
Были у этой компании и некоторые особенности: жёсткие внутренние регламенты, которые требовали использования собственных и сторонних ИТ-ресурсов для создания специализированных бизнес-решений. Поэтому в ОБК активно использовалось самописное ПО, а также приложения, разработанные подрядчиками. А неповоротливость, присущая многим крупным компаниям, повлекла за собой появление разветвлённой, но не слишком удачно структурированной ИТ-инфраструктуры. К счастью, благодаря хорошей работе штатного технического отдела оборудование справлялось с текущими нагрузками.
Руководство заметило, что на ИТ-отдел ложится повышенная нагрузка, и стало изучать способы оптимизации этого направления. Так появилась идея переноса инфраструктуры в облако.
Сказать по правде, первое знакомство ОБК с провайдером облачных решений не задалось. Но это не отпугнуло её, а помогло лучше сформулировать свои цели и потребности, а также подготовить перечень требований к облачным провайдерам. И впоследствии, когда потребовалось организовать быструю и стабильную работу программы лояльности клиентов, ОБК без труда организовала тендер, в котором изложила свои «хотелки». Для отсева слабых кандидатов торги разделили на две части, предварительную квалификацию и тендер.
Квалификация включала в себя оценку претендентов по списку из большого количества критериев. Были заданы жёсткие требования по опыту работы, деловой и общей репутации, надёжности, финансовому благополучию и т.д. Изначально на тендер заявилось много компаний, но пробиться во второй этап смогли лишь две. И предложение Cloud4Y, попавшего в финал, оказалось более убедительным..
Первые сложности
Возможно, вас удивит, но главным препятствием к активному внедрению облачных решений в ОБК был… страх. Страх того, что облака сделают бизнес хуже. Эти опасения возникли в том числе из-за неудачного первого опыта миграции. Кроме того, руководители ОБК беспокоились, сможет ли компания-подрядчик справиться с ответственной задачей по переносу объёмной и нетиповой ИТ-инфраструктуры.
Долгое время в ОБК использовалась сложная архитектура файловой системы действующего сервера. Она строилась на аппаратном и программном RAID-массивах. Программный запускался под Linux.
Кроме того, внутренний регламент службы безопасности исключал возможность интернет-доступа представителей ОБК к железному серверу. Физический доступ к серверу тоже был ограничен. Это потребовало от инженерной команды провайдера недюжинных навыков в social engineering и знания разных консольных фокусов, которые позволили найти обходной путь для безопасного переноса данных.
Здорово потрепали нервы наших инженеров действовавшая через пень-колоду система резервного копирования, невозможность получить административный доступ к консоли сервера (внутреннее ПО такого функционала не предусматривало). Фактически, ИТ-отдел Cloud4Y выступал в роли сапёров. Одна неверная команда, и базам мог настать конец. А там — цепная реакция, и обязательно «ляжет» что-нибудь ещё. Чем это грозит крупному бизнесу, от которого зависят многие другие? Наверное, объяснять не нужно.
Возвращаясь к теме непростого первого опыта ОБК с облачными решениями, хотим отметить максимально некорректное поведение компании, первой занимавшейся вопросом миграции ОБК в облако. Несмотря на явные проблемы в своём сервисе и испорченные отношения с клиентом, они искусственно затягивали процесс перехода в наше облако. Срывались встречи, «забывались» доступы к собственному оборудованию, вставлялись палки в колёса при переносе данных клиента.
С одной стороны, можно понять нежелание терять крупного клиента. Но с другой — это всё же неэтично. Ответственный бизнес не позволяет себе так относиться к клиентам и/или конкурентам. Разрыв отношений всегда является последствием недоработок как минимум одной из сторон. И это должно стать поводом для улучшения сервиса, а не строительства козней.
Миграция
Инфраструктура ОБК была большая и сложная, поэтому мы решили переносить её в три этапа. Сначала — перенос в облака около 6 Тб данных. Это большой объём, требующий много времени. Поэтому ИТ-специалисты Cloud4Y решили не рисковать, вместо переноса виртуальных машин взяв бэкап SQL. Бэкапы занимали 900 Гб, что позволило сэкономить ресурсы.
Затем инженеры перенесли вспомогательные ВМ, используя стандартные средства резервного копирования на базе VMware. И на третьем этапе перенесли физический сервер на более качественное железо. Это было критически важно, потому что использовавшаяся ранее конструкция была, мягко говоря, плохой.
Третий этап потребовал стал наиболее сложным и трудозатратным. Специально разработанное для ОБК ПО сторонних подрядчиков (получившее массу ярких и красочных эпитетов от технического отдела) не предусматривало возможность переустановки сервера. Требовался именно перенос один-в-один. Ну не знали разработчики софта, что серверы иногда переустанавливают. Что делать, бывает.
А ещё сервер немножко не работал. Именно так. Периодически он сбоил и отключался. И каждый раз это было внезапно, так что скучать инженерам не приходилось.
Дополнительная работа
Подсознательно понимая, что миграция в облако может быть трудной, ещё до старта мы создали настроенную под клиента инфраструктуру — защищённые туннели, шлюзы, внутреннюю сеть. Развернули ВМ, на которых должны работать сервера. Это позволило выполнить перенос в штатном режиме даже с учётом описанных ранее сложностей.
К физическому серверу мы примапировали GPU Nvidia Tesla P100, которая была нужна для сложных вычислительных операций, регулярно выполняемых внутри ОБК.
Такая подготовка дала ещё одно преимущество. По договору миграцию нужно было выполнить за три дня, но мы всё сделали за два. В четверг был подписан договор, а вечером пятницы представители ОБК подтвердили приём работ по миграции.
Итоги
Мы предоставили ОБК гибкую масштабируемую инфраструктуру, защищённую от доступа извне. БД доступны только по защищённому каналу только ограниченному кругу лиц, пользующихся доверием сотрудников ИБ в ОБК.
Бизнес получил инфраструктуру, которая намного превосходит возможности той, что была ранее. Появились и дополнительные возможности. Так, наши инженеры настроили мониторинг серверов, внедрили новые технологические решения для более эффективной работы оборудования. Позаботились и о создании нормально работающей системы резервного копирования, до этого функционировавшей невесть как.
В итоге ОБК получила полноценный консольный доступ к инфраструктуре и бэкапирование всех систем, что снизило нагрузку на штатную ИТ-службу и свело к минимуму риск потери данных.
На платформе Cloud4Y расположены не только виртуальные машины ОБК, но и их физический сервер, который тоже планируется виртуализировать, чтобы сократить расходы на поддержку и обслуживание.
Что ещё даёт миграция в облако Cloud4Y:
- Возможность распределения системы между разными дата-центрами для её повышения отказоустойчивости
- Удобную систему резервного копирования с возможностью переноса бэкапов в другой дата-центр
- Надёжного хостера, помогающего оптимизировать издержки на ИТ-инфраструктуру, не ограничиваясь простым размещением сервера клиента
- Снижение затрат на использование GPU-серверов
