Инженерная инфраструктура центров обработки данных (ЦОД)

Выступление Михаила Суконника, компания Radware на конференции по теме «Инфраструктура и решения для серверных и ЦОД», которая успешно прошла в Екатеринбурге 15 сентября. Смотрим видео и читаем.

     Поскольку организация DOS-атак на конкурентов – национальный спорт в России, качественная атака стоит 300$ в день. У кого есть Интернет, наберите в Яндексе по-русски «заказать DOS-атаку». Получите от шести до восьми страниц ссылок со всякими маркетинговыми ходами типа «закажите на два дня — получите третий бесплатно». И это вещь актуальная, это реально происходит ежедневно. Кто еще не встречался, готовьтесь.

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

Как добиться эффективности в дата центре?

Мы тут все говорим о повышении эффективности, но обычно на конференциях по центрам обработки данных разговор в основном идет о том, как сделать более эффективными энергообеспечение и капитальные затраты. Основное слово на конференциях по дата центрам – это коэффициент энергоэффективности PUE. Это всё так, но зачастую, говоря о том, как оптимизировать энергообеспечение, охлаждение и прочее, мы забываем о том, для чего данный центр обработки данных существует. А он, собственно, для того, чтобы не экономить электроэнергию, а чтобы там работало некое оборудование, в основном современное, по которому бегают какие-то аппликации и приложения. Я буду говорить о том, как добиться эффективности использования именно серверного оборудования.

Консолидация дата центров

Тренды, которые сегодня есть, – либо мы сами ходим под этими флагами, либо нам указывают сверху: «Это правильная вещь, идите туда». Это объединение центров обработки данных, когда много маленьких объединились в один большой – коммерческий или корпоративный дата центр. Это создание сервисно-ориентированной инфраструктуры дата-центра, архитектуры ЦОДа и виртуализации. Виртуализацию мы уже тут упоминали, про пиво с водкой просто чудесная, кстати, была аналогия. О пиве была очень правильная картинка: когда примерно 25-30% составляла пена. Так обычно и получается.

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

Об CAPEX и OPEX

Затраты у нас состоят из двух других правильных слов, которые мы часто произносим: это капитальные инвестиции и операционные расходы. Соответственно, от нас хотят, чтобы мы снизили и то, и другое. Я не буду говорить, из чего они состоят: мы все это знаем. Если мы говорим о серверах и аппликациях, то у нас есть в CAPEX стоимость X-серверов, лицензий и так далее. И в OPEX, которым еще некоторое время назад пугали, а теперь мы только о нем и говорим, кроме электричества есть еще стоимость лицензии на эти сервера, стоимость их обслуживания, ЗИПы, которые нужно содержать, люди, которым нужно платить. Мы, кстати, про электричество забываем, что кроме серверов и оборудования, которое там установлено, нам нужно содержать энное количество инженеров, которые будут всё это обслуживать.

Снижение количества серверов – путь к повышению эффективности

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

Балансировщики нагрузки на сервера и акселераторы

Пару лет назад говорилось о двух типах оборудования: о балансировщиках аппликации и об акселераторах. Чтобы понять, что они делают, давайте представим, что их нет. К нам валятся некие запросы от клиентов, есть некое количество серверов, в которых прыгает аппликация, и мы неким образом распределяем эти запросы. Чтобы не углубляться в технические термины, скажу, что мы можем рассылать их по очереди, с какими-либо коэффициентами, а можем придумать какое-то другое правило рассылки. Причем надо понимать, что это мы придумали правила. То есть, это мы изначально сказали: «Кто пойдет направо – коня потеряет, кто налево – голову сложит». На самом деле никто не проверяет тех, кто пошел направо и налево: реально ли они там лошадь потеряли или голову сложили. А мы анализируем то, что реально происходит, поскольку посылаем запросы. Если мы послали одинаковое количество запросов на 100 серверов, при этом с одних ответ идет медленнее, с других – быстрее, значит, на те, с которых ответ идет медленнее, нужно посылать меньше запросов.

     Это один из примеров. Реально мы анализируем 19 различных групп параметров с различными схемами анализа того, что делать. Разместив систему балансировки нагрузки на серверы, мы добиваемся ситуации, при которой независимо от того, на какой север попадет удаленный клиент, он всегда получит одинаковый уровень обслуживания. И при этом все серверы будут загружены примерно одинаково. Не будет ситуации, при которой нам звонит директор: «Я только что кликнул на сервер N, и он долго грузился». Мы знаем, что у нас сидит Вася, кликает — и у него всё нормально работает. Если у кого-то плохо — значит, у нас реально заканчиваются мощности. Если у кого-то хорошо – значит, и у всех будет хорошо. Чтобы у нас не возникало ситуаций, при которых одни серверы перегружены, а другие не перегружены, мы просто наращиваем количество серверов. Если звонит директор и говорит: «Ребята, у меня плохо работает», — мы покупаем еще десяток серверов, «размазываем» нагрузку и некоторое время живем спокойно – до следующего такого же случая. Обычно ситуация такова, что количество серверов избыточно. За счет балансировки нагрузки на серверы мы можем сэкономить 10, 15, 20% серверов.

Балансировщики нагрузки на сервера и акселераторы

Вторая вещь, которая приводит к наличию лишних серверов. В большинстве случаев серверы занимаются не только самой аппликацией, но и кучей вещей вокруг: например, известными всем шифрованием, которые могут занимать до 60% мощности сервера. Кроме того, есть такие вещи, как кэшинг, которые мы тоже на него вешаем. Если у нас много коротких сессий, как в банковских операциях, это тоже отнимает некие мощности сервера – от 4 до 5%. Таких вещей очень много, и это не есть основная функция сервера. Было бы логично забрать эти функции у всех серверов и отдать их некой одной внешней «железке». Такой «железкой» является балансировщик – акселератор под названием «Alteon», который широко известен в России.