Прекратите использовать сервера, как крупный рогатый скот, а не домашних животных

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

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

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

По словам Эдварда Халетки, генерального директора AstroArch Consulting в Остине, штат Техас, главной причиной для лечения серверов, как крупного рогатого скота, является борьба с конфигурацией дрейфа. Но админам легко разбить совершенно однородное стадо крупного рогатого скота в кучу домашних коров, даже если все действуют с лучшими намерениями. Основной проблемой администратора операционной системы должно быть определение основной причины проблемы сервера и обеспечение ее не повторения на любом сервере. Если каждый сервер обрабатывается отдельно, становится невозможно узнать, что вызвало данную проблему безопасности или производительности. «Вы пытаетесь решить эту проблему для каждой отдельной машины, а не для всего вашего стада крупного рогатого скота», — сказал он.

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

Ручное управление поставщиком облака

Облачные провайдеры отталкивают ИТ-администраторов.

«Администраторам трудно привыкнуть к идее, что если вы на платформе, это может привести к внезапным свертываниям или прекратить их», — сказал Кен Бирман, профессор компьютерных наук Корнельского университета в Нью-Йорке.

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

Мощный пользовательский облачный экземпляр, вероятно, пока не сработает. ИТ-специалисты хотят выжать наибольшую производительность из определенной суммы денег, предусмотренной бюджетом в мире обостряющихся расходов. Но минимально настраиваемый сервер также минимально эффективен, и возможность настраивать профиль ресурсов, настройки ядра или топологию сети практически не существует в облаке. Если это сработает, администраторы должны ожидать плохую производительность, потому что они работают против дизайна веб-служб Amazon (AWS), Microsoft Azure или других поставщиков облачных хостингов. Небольшой сверхприведенный, но стандартизованный экземпляр облака будет предлагать лучшую производительность и, вероятно, лучшую экономию по сравнению с физическими затратами на запуск этого сервера внутри компании.

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

Здесь, предположил Бирман, метафора животного происхождения должна быть сдвинута ​​от крупного рогатого скота и домашних животных, до флотилии.

Серверы различного размера, которые обслуживают множество приложений, сродни флоту транспортных средств в сфере доставки. Однородность по-прежнему царит, но неэффективно автоматизировать тот же самый сервер для простого приложения, также, как для сложного. Таким образом, администраторы, вероятно, по-разному выбирают работу сервера на основе каждого приложения. Большие и более сложные приложения требуют более тяжелых серверов — назовите эти полуприцепы. Легкие приложения, которые быстро расширяются и опускаются, могут находиться на гораздо меньших серверах — назовем их автомобилями. Переведенные в облачные опции AWS, они напоминают разницу между экземплярами Elastic Compute Cloud M4 и M3. Администраторы должны иметь возможность использовать «полуприцепы» так же эффективно, как и «автомобили для доставки».

«Вы действительно управляете большой коллекцией машин, которые вы приобрели как [эластичный] парк компьютеров», — сказал Бирман. «Система будет изменяться под размер автоматически».

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

Не позволяйте коровам покидать ферму серверов

Несмотря на очевидную легкость управления стадом или кластером серверов, ни один из методов не поддерживает обслуживание. Например, администраторы ИТ-операций должны управлять балансировщиком нагрузки для управления рабочей нагрузкой на динамическом флоте, а также изучать серверные системы хранения и распределенные таблицы кэша, которые хранят данные приложения. Техническое обслуживание должно быть максимально удобным для предотвращения несоответствий; изменения проходят через репозиторий инфраструктуры как код, чтобы обеспечить точное развертывание. Если вы будете следовать правилам, вы получите устойчивую, прогнозируемую масштабируемость, но вы не сможете игнорировать серверы.

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

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

Сценарий встречи DevOps

DevOps — это улица с двусторонним движением: профессионалы по операциям должны понимать свои приложения, а разработчики должны понимать, как эти приложения развертываются.

Команды OPS и Dev должны собираться вместе с командами безопасности. Компонент A может потребоваться в приложении Z для соответствия нормативным требованиям, но не предполагайте, что разработчики это знают. «Существует намного больше возможностей для создания хорошо написанной среды, чем разработчики, говорящие:« Мы собираем сценарий установки этого приложения », — сказал Халетки.

Если ветеринар говорит, что конкретные отруби жизненно важны для здоровья вашего крупного рогатого скота, вы не собираетесь кормить их яблоками. Если руководители проектов заявляют, что приложение нуждается в элементах A, B и C, разработчики не должны вместо этого вводить D, E и F. И если законность говорит о том, что приложение должно быть физически отделено от других приложений, операции не будут разворачиваться на мульти- облачное публичное облако, независимо от того, насколько надежны меры безопасности. Все, кто заинтересован в применении Z, должны внести свой вклад в создание базового образа, чтобы убедиться, что развертывание отвечает всем его потребностям и стандартам в первый раз.

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

 

Поделиться в социальных сетях:

Добавить комментарий