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

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

Лезвия

Лезвия дают заметное преимущество с точки зрения плотности размещения. Поскольку пространство в стойках является дефицитным, понятно, что высокая плотность — это хорошо. Многие эксперты указывают на централизованное управление в качестве достоинства лезвий. Верно, управление лезвиями осуществляется централизованно. Через единый интерфейс вы можете работать со всеми вашими лезвиями. Вы можете создавать профили серверов, добавлять сети передачи данных, добавлять сети хранения (SAN), настраивать виртуальные локальные сети, управлять питанием и вообще использовать для работы с вашими системами весьма мощные инструменты. Вы можете также подключиться к своей системе управления лезвиями по протоколу SSH (Secure Shell) и вводить команды с клавиатуры в интерактивном режиме. Например, отдельному лезвию можно выдать команду на перезагрузку, что имеет практически тот же эффект, что и его физическая перезагрузка.

Это некоторые из очень значительных преимуществ серверов-лезвий.

Что касается их недостатков, то это дороговизна. Лезвия действительно дороги. Кроме того, они требуют особых силовых разъемов. Кроме того, вы оказываетесь привязаны к определенному производителю, когда приобретаете корпус или шасси. Вы не можете купить лезвия производства Sun, HP и IBM и смонтировать их в одном корпусе. Будем надеяться, что какая-нибудь сторонняя компания заметит потребность в интероперабельности такого рода и создаст корпус, в который можно будет помещать самые разные лезвия. Ко всему прочему у лезвий есть одна интересная особенность: вы не можете добавить или удалить сеть либо SAN при работающем лезвии. Это большой недостаток.

Вопреки распространенному мнению (возможно, его придерживаются те, кто пишет на эти темы, но в действительности никогда не видел лезвий и не работал в ЦОДе) лезвия не соответствуют требованию “подключи и работай”. Их настройка осуществляется вручную. На практике я могу настроить стандартный стоечный сервер гораздо быстрее, чем лезвие. Мало того, я могу сконфигурировать стандартный сервер в качестве производственной системы быстрее, чем соответствующее лезвие. Почему? Настройка лезвия сложнее и требует отключения питания при выполнении определенных работ, хотя после конфигурирования и ввода в эксплуатацию это практически та же зверюга, что и стандартная серверная система.

Хотя плотность размещения лезвий выше, часто вы можете видеть в стойке максимум два корпуса из-за их большого веса. Два полностью заполненных корпуса могут весить свыше 400 кг. Это создает большую нагрузку на незначительную площадь. Таким образом, высокая плотность сводится на нет из-за невозможности разместить в стойке четыре корпуса.

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

Стандартные системы

Под стандартными системами я подразумеваю монтируемые в 19-дюймовую стойку серверы высотой 1U, 2U, 4U и т. д., имеющие собственные особые разъемы для подключения питания и сети, локальные диски и адаптеры HBA/SAN, присоединяемые к KVM-переключателю или консольному серверу. Некоторые достоинства стандартной системы касаются того, что относится к недостаткам лезвия, и наоборот. Стандартные системы имеют компоненты plug-and-play, такие как сетевые адаптеры, диски и блоки питания. Нет необходимости выключать систему, чтобы произвести соответствующие изменения. Наличие локального DVD-дисковода также является большим преимуществом. Мне нравится возможность вставить диск DVD, установить ПО или ОС и вернуться к своим делам. Конечно, вы можете сделать это с помощью механизма управления серверами при отсутствии физического доступа к ним (Integrated Lights-Out, iLO), но столкнетесь при этом с некоторыми проблемами из области надежности, которые не возникнут, если действовать, как учит старая школа.

Стандартные серверы являются независимыми. Это означает, что я могу где угодно установить их в любую 19-дюймовую стойку. Мне не нужны специальные кабели, блоки питания или корпуса. При необходимости я могут установить сервер в ЦОДе прямо на полу и запустить его, стойка не требуется. Стандартные серверы дешевле или, я бы сказал, доступнее, чем лезвия.

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

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

Сходные аргументы: физические устройства против виртуальных

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

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

Но есть несколько верных ответов.

Используйте лезвия, если:

  • вы можете позволить себе это и готовы их использовать;
  • вам необходима более высокая плотность размещения и ваши конструкции выдержат соответствующий вес;
  • у вас имеются опытные, обученные администраторы лезвий;
  • вы готовы мириться с их чудачествами;
  • вас не смущает привязка к определенному производителю.
  • Используйте системы стандартной архитектуры, если:
  • у вас ограниченный бюджет;
  • вы не желаете замыкаться на конкретном производителе;
  • вам необходимо быстрое развертывание;
  • вы предпочитаете стандартные процедуры управления (старую школу);
  • у вас достаточно мощные системы охлаждения и электропитания и хороший воздухообмен, позволяющие размещать стандартные системы.
  • у вас достаточно мощные системы охлаждения и электропитания и хороший воздухообмен, позволяющие размещать стандартные системы.

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