Эволюция отменяется. Почему инфраструктура в компании похожа на лоскутное одеяло
14.10.2020, Ср, 20:39, Мск , Текст: Шатунова Евгения
Конвергентную и гиперконвергентную структуру часто рассматривают как ступеньки на лестнице внутренней эволюции ИТ-инфраструктуры компании. От разрозненных «клеток»-компонентов мы постепенно идем к более сложным «организмам», а вершина этой горы — программно-определяемый ЦОД.
Казалось бы, эта эволюция происходит так: организация с классической трехуровневой инфраструктурой, в которой хранилища данных, сетевые и серверные ресурсы были приобретены отдельно друг от друга и у разных производителей, собраны в систему и управляются по-отдельности множеством администраторов, вдруг решает изменить положение дел. Минусы были налицо: такой тип инфраструктуры можно проектировать месяцами, а потом она ест дорогие человеко-часы квалифицированного персонала. Хорошо бы уйти от этого. Перестраиваемся — и вот имеем кое-что более удобное: конвергентную структуру. Ее проще развернуть, а развернутым решением легко управлять из единого окна, в котором видны все элементы. Последние можно купить не по отдельности, а в стойке — и сразу же начать работать.
Поднимаемся выше, и вот уже инфраструктура гиперконвергентна. Больше нет отдельных элементов, есть модульные системы. Серверное оборудование унифицируется, устройства объединяются в кластеры, решение становится программно-определяемым. Инфраструктуру можно ставить «из коробки», а число администраторов сокращать. Таким образом мы получаем фундамент, на котором можно построить полностью программно-определяемый ЦОД.
Дарвиновская эволюция, только в ИТ
Инфраструктура изменяется, приспосабливается и становится лучше. Так было бы в идеальном мире. На деле так никто не делает. Компании продолжают использовать классический подход. Отчасти по историческим причинам. Многие годы они накапливали технологии, и пока просто не могут взять и перейти на что-то другое. Работает — не трогай. Это всё ещё действенный инженерный подход. Есть компании, которые пользуются софтом двадцатилетней давности, написанным ещё под мейнфреймы. Неудивительно: еще 10 лет назад представители IBM (компании, которая создала сам термин) в России называли нашу страну «одной из немногих, где число новых пользователей мэйнфреймов бьет все рекорды». Мейнфреймы пользовались хорошей репутацией: они были надежными, масштабируемыми и доступными по цене. То, что нужно для крупной коммерческой или государственной организации. Даже в самой современной компании есть такие области и процессы, которые сложно и не очень нужно «перетаскивать» на какие-то новые решения.
Садимся не в свои сани
Проект, выбранный не под себя или неправильно, может принести не выгоды, а проблемы. В результате даже сформировалось мнение, что сам термин «конвергентная» инфраструктура — маркетинговый. Под конвергентной системой продавались обычные классические серверы, а к ним прилагались СХД и коммутаторы. «Так многие считают, и можно сказать, что отчасти они даже правы, — замечает Алексей Никифоров, руководитель отдела технологических решений, Hitachi Vantara. — Часто маркетинг забегает вперед, оставляя без внимания проблемы технологий. Но одно совершенно точно: конвергенция значительно упрощает жизнь администратора и его начальства. Меньше человеческих ошибок. Когда у нас есть набор сертифицированной аппаратной части, которую до развертывания уже протестировал изготовитель, когда есть единое окно управления, позволяющее одной кнопкой запустить обновления прошивок, тогда мы избегаем проблем на границе сети. Нет ситуаций, когда оборудование или ПО оказалось с чем-то несовместимо, или какое-то обновление поставили раньше, чем это было необходимо. Банальное обновление стандартного софта — и вдруг всё «упало». Частая проблема, даже несмотря на все регламенты компании. Конвергенция позволяет минимизировать неприятности такого рода».
С гиперконвергенцией у компаний может возникнуть проблема не очень хорошей масштабируемости на определенных типах приложений. Из-за этого первоначальный восторг от приобретения и запуска нового типа инфраструктуры проходит, и ее перебрасывают под какие-то определенные задачи или проекты. В большой организации всё пригодится. Получается, что практикуется подход в духе: купили, протестировали, не подошло — не выбрасывать же? «Это и рискованно. Никто не хочет отвечать за ошибки, все аккуратные. По этой же причине вы не найдете неуспешных кейсов. Купили, радуются, а спросишь через два года про использование — не используют, задвинули на какие-то задачи», — комментирует Алексей Никифоров.
Довольно часто конвергенцию и гиперконвергенцию заворачивают в яркие фантики экономии и супервыгоды, но на деле все не так
Программно-определяемый ЦОД и вовсе — прерогатива далеко не каждой компании. В основном такой центр нужен сервис-провайдерам, бизнес которых ориентирован на большой пул заказчиков, множество мелких разнотипных задач, выполняемых разными подразделениями. Такой бизнес требует больших изменений с точки зрения инфраструктуры. Либо они просто построились недавно и сразу перешли на самое новое, что может предложить рынок. Им не нужно тянуть за собой историю.
Инфраструктуру старых и крупных компаний лучше всего сравнить с петербуржским Зимним дворцом. Казалось бы: сейчас там всё должно быть так же, как в других домах, к которым мы привыкли — электричество, водяное отопление, вентиляция — то же самое, что в любом торговом центре. Но старое и крупное сооружение до сих пор содержит в себе не только новые изобретения, но и инженерные сооружения, которым уже 200 лет. И они работают, так зачем же их выдирать оттуда? Точно так же и компании не спешат отказываться от старого. «У наших заказчиков конвергенция и гиперконвергенция присутствует «кусочно», — говорит Алексей Никифоров. — Обычно гиперконвергенция используется в продакшн-компаниях под среды разработки и тестирования. Большие компании другого профиля относятся к ней осторожно. Почему? Представим классическую СУБД. Это всё-таки монолитная вещь, несмотря на все разговоры о контейнерах и других новых фишках. Растянуть её на гиперконвергентное решение получается далеко не всегда из-за разных технологических нюансов».
Без калькулятора жизни нет
Довольно часто конфеты конвергенции и гиперконвергенции заворачивают в яркие фантики экономии и супервыгоды. Но это не всегда правда. Делаем хорошо работающее высокопроизводительное решение, считаем дополнительно все лицензии — и может оказаться, что деньги вовсе не экономятся. Но куда деваться ИТ-директору, вынужденному защищать предложение в отделе финансов?
«Наверное, ни про одно решение нельзя точно сказать, что оно на 100 процентов дешевле, — объясняет Алексей Никифоров. — Тут надо хорошо просчитать все факторы: что вы будете размещать, насколько планируете расти, какую производительность хотите получить в конечном итоге. Если у компании большие монолитные серверы со ста написанными приложениями — никуда она от него не убежит и в гиперконвергентное решение не «засунет». Может так случиться, что приложение, работающее на больших вычислительных ресурсах будет плохо работать в гиперконвергентной инфраструктуре. Или хорошо, но придется потратить на дисковые ресурсы столько, что лучше бы построить традиционную систему, в которой можно наращивать компоненты».
Интересен и такой факт: компании покупают конвергентные решения, а потом вдруг начинают использовать их в своих классических подходах: кастомизируют, ставят такие компоненты, которые уже не поддерживаются в рамках целого. Получается, что такая инфраструктура де юре всё ещё конвергентная, в отчетности именно так, а де факто — это классическая трехуровневая архитектура.
Никто не меняет свою инфраструктуру полностью. Бывает по-другому, когда при запуске крупного проекта специально под него выбирают платформу и тип инфраструктуры. Или, когда компания решила переехать из облака в собственный ЦОД, строит его с нуля. В облаке уже существуют виртуальные машины, их не надо создавать, всё понятно по нагрузкам, есть статистика — тогда решение по полной смене инфраструктуры оправдано. Вот тут даже будет наблюдаться экономия. Важно не поддаваться трендам бездумно. Чтобы не попасться на удочку маркетинга, необходимо понимать: не каждое приложение подходит под гиперконвергентную инфраструктуру, всё нужно тестировать, снимать текущую нагрузку, анализировать, считать, наконец, плотно общаться с вендором.
«Наша компания продает все три типа инфраструктур. А если говорить о гиперконвергенции, то у нас есть решения совместно с VMware, мы поставляем аппаратные компоненты для их знаменитого vSAN, преимущества которого всем известны. Гиперконвергенция — это хорошая вещь, если правильно оценить её возможности и применять по назначению», — резюмирует Алексей Никифоров.
Полный текст статьи читайте на CNews
