Прогулки по серверному парку

Материал предоставлен сайтом ITC Online.

Как делят серверы

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

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

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

Аппаратная база таких продуктов варьируется от многопроцессорных RISC-систем с возможностью установки более сотни процессоров, систем, допускающих "горячую замену" практически любого критически важного компонента (процессоров, дисков, блоков питания, вентиляторов, контроллеров и модулей памяти), до скромных одно- и двухпроцессорных на платформе х86 без возможности замены компонентов "на ходу". Последние характерны для массового рынка, о них в основном и пойдет речь.

Более важной для принятия решения при строительстве ИС представляется классификация серверов по функциональности. Исходя из распределения по масштабу, трудно судить однозначно, можно ли эффективно решать все IT-задачи предприятия, отдела или рабочей группы с помощью сервера соответствующей мощности. Иногда для тысяч пользователей сервер с 4-6 процессорами может оказаться избыточным, а небольшая, но очень активная рабочая группа в состоянии "освоить" на 100% производительность и более мощных систем.

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

Остановимся на некоторых наиболее распространенных типах серверов с различным функциональным назначением.

File Server

Файловый сервер (File Server), пожалуй, ветеран серверного парка, обеспечивает совместное использование дискового пространства и размещенных на нем данных.

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

Факторами, определяющими вычислительную мощь файлового сервера, являются: производительность дисковой системы и сетевых интерфейсов, объем оперативной памяти для кэширования данных, быстродействие используемой в установленной ОС файловой системы и только в последнюю очередь - производительность процессора. Тем не менее в некоторых случаях может возникнуть потребность и в процессорной мощности. Например, при реализации сервером антивирусной защиты - проверки "на лету" файлов, поступающих по скоростным сетевым интерфейсам, или же в ситуации с включенным программным сжатием данных (в NTFS или Novell FS). Заметим, что здесь хорошо себя зарекомендовали SMP-системы.

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

Скоростные параметры сетевых интерфейсов, как ни странно, вовсе не являются лимитирующим фактором производительности файл-сервера. В подавляющем большинстве случаев одной-единственной сетевой платы 10/100/1000 MBps вполне достаточно для любых объемов файлового ввода/вывода, однако для нее желателен интерфейс PCI 64-бит/33 MHz (а лучше 64-бит/66 MHz), а для достижения максимального быстродействия - работа с Jumbo Frames. Под последним скрывается название технологии передачи данных, при которой вместо обычных 64-1500-байтовых пакетов по сети пересылаются 8 KB, что снижает количество пакетов и, соответственно, нагрузку на процессор сетевого адаптера и маршрутизатора. Выигрыш в производительности может доходить до 10-15%, а в отдельных случаях и до 30%. Однако, например, в терминальной системе возможно снижение быстродействия.

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

SQL Server

SQL Server - пожалуй самый интересный объект из области серверов, требования к которому являются дополнительными по отношению к файловому серверу. Причиной создания системы обработки структурированных запросов послужила задача масштабирования файл-серверных решений по работе с БД. Проблем тут несколько - это и то, что сеть не в состоянии обеспечить скорость доступа к данным, сравнимую с "внутримашинной", и блокировка данных (для сохранения их целостности и связанности), возможная только на уровне целого файла, и, наконец, аварийные разрывы соединений (неизбежные при неидеальных клиентских местах), так опасные для данных.

Работа SQL-сервера основана на весьма простой идее - клиентская станция присылает запрос, который обрабатывается средствами сервера, после чего результаты запроса возвращаются. При этом все операции по управлению данными, контролю целостности и связанности (а при использовании так называемых "хранимых процедур" и по выполнению логики приложения) возлагаются на программное обеспечение сервера. Такой подход решает ранее очерченные проблемы, но в ответ порождает новые. Самой главной из них является то, что на сервере сосредотачивается вся нагрузка по обработке данных. Если при файл-серверной архитектуре обработкой занимаются рабочие станции, то в клиент-серверной эта нагрузка ложится фактически на одну систему. Соответственно, при проектировании такого сервера основное внимание уделяется следующим параметрам:

Пропускная способность оперативной памяти при произвольной выборке. В данном случае этот показатель можно назвать решающим, так как современные процессоры с большими коэффициентами умножения практически всегда испытывают недостаток в пропускной способности памяти при любых кэшах.
Размер оперативной памяти. В идеале он должен быть таким, чтобы помещались все рабочие таблицы, индексы, временные таблицы, хранимые процедуры и пр. Но, к сожалению, даже для 1-2 GB данных это может составить десятки гигабайт. Поэтому приемлемой следует признать ситуацию, соответствующую классическому правилу 80:20, где 80% запросов приходится на 20% информации и наоборот. Иными словами, желательно разместить в оперативной памяти это самое "горячее пятно", к которому можно отнести индексы данных, хранимые процедуры и наиболее часто используемые данные. Этот вопрос приходится решать каждый раз по-новому вместе с разработчиками приложений, но в общем случае (чисто эмпирически) сделаем предположение, что для достижения некоторой приемлемой производительности объем памяти должен составлять не менее 256-512 MB на каждый гигабайт данных.
Процессорная мощность. Как уже упоминалось, в этом случае основная подсистема играет ключевую роль. Особенностями нагрузки на процессорную часть являются высокая степень ветвления кода с малой степенью предсказуемости, поблочная обработка данных, большая нагрузка на память (причем именно с произвольной выборкой). Исходя из этого "идеальный" процессор сервера БД выглядит как имеющий, с одной стороны, минимальный конвейер, а с другой - максимальный объем иерархии кэш-памяти (в том числе и первого уровня) и некоторый, не слишком большой коэффициент умножения. Весьма неплохо, если процессоры могут нормально (гладко) адресовать большую память, достаточную для размещения базы данных. Например, при размере БД в 5-7 GB обычный Рentium III будет пользоваться "подкачкой", что необязательно для Xeon с его большим объемом кэш-памяти.

Все эти ограничения взаимосвязаны. Так, при непродуманном построении SMP-систем никакая архитектура памяти не сумеет предоставить каждому процессору требуемую пропускную способность при приемлемом уровне задержек. Впрочем, даже коммутируемые архитектуры не в состоянии обеспечить необходимого времени отклика оперативной памяти, поэтому во избежание простоев процессоры серверов БД обычно оснащаются большим объемом кэш-памяти со сложной иерархией. Для "тяжелых" серверов, работающих с сотнями запросов и многогигабайтными базами, нелишними являются 4-8-16 MB кэш-памяти.

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

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

NNTP Server

Сервер конференций (NNTP Server) служит для совместного доступа пользователей к некой структурированной информации (конференции), упорядоченной по тематике (Thread) и времени. Его принципиальное отличие от электронной почты в том, что процесс обсуждения происходит публично, и круг общения практически не ограничен. NNTP Server можно признать частным случаем файлового сервера - достаточно представить себе, что это система с единственным клиентом (ПО промежуточного слоя), размещенным на ней же. Соответственно, подавляющее большинство требований к файловому серверу можно без изменений перенести и на сервер телеконференций. Единственное различие в том, что при высокой нагрузке такая система может испытывать потребность в процессорной мощности. Более того, действительно сильно нагруженный сервер вполне может требовать значительной вычислительной мощности, такой, что станет актуальной установка двух процессоров (но не более того). Интересно, что при этом нагрузка на память сравнительно невелика.

DNS/DHCP Server

С точки зрения необходимых ресурсов рассматриваемые системы, а также другие серверы сетевых служб (Router and Traffic Monitoring) не имеют каких-либо жестких требований. Критичными параметрами являются, пожалуй, скорость отклика на запрос и стабильность работы системы. Все очевидным образом упирается в задержки цепочки "сеть-память-процессор-память-сеть" и операционную систему. На деле роль сервера DNS/DHCP может выполнять практически любой ПК с достаточным объемом памяти, надежной ОС, приемлемой отказоустойчивостью работы (ECC) и хранения данных (например, зеркалирования IDE вполне достаточно). Лимитирующим фактором в таком случае являются скорости внешних сетевых интерфейсов, редко превышающие 10 Mbps.

Firewall/Gateway Server

Пользователь должен иметь соответствующее клиентское программное обеспечение и быть авторизованным в базе Firewall, что дает возможность контролировать доступ на уровне клиента и регистрировать трафик. Серверы приложений и посредники обеспечивают жесткий контроль входящих и исходящих данных. Программно-аппаратный комплекс Gateway (шлюз) соединяет разнородные сети или сетевые устройства и позволяет решать проблемы, связанные с различием протоколов и/или систем адресации. В сети Internet шлюзом часто называется межсетевой маршрутизатор (router).

Ключевым требованием, предъявляемым к системам обеспечения безопасности (Firewall), является, естественно, устойчивость их ОС. Идеальны в этом отношении закрытые системы типа Cisco IOS, Solaris или любая ОС в "усиленной" конфигурации - например FreeBSD. Производительность аппаратного обеспечения тут важна менее всего, хотя при высокой нагрузке желателен более или менее мощный процессор. Однако, как и в предыдущем случае, лимитирующим фактором является скорость внешнего соединения - сетевого интерфейса. Например, если соединение в состоянии пропустить не более, к примеру, 2000 пакетов в секунду, то способность фильтра обрабатывать 20 тыс. пакетов останется невостребованной и приведет только к перерасходу средств. Особых требований к системам хранения данных не предъявляется, так как практически ничего не хранится (в идеале - система загружается из ПЗУ, а правила работы берутся либо из CMOS, либо с дискеты), а для бесперебойной работы достаточно ЕСС-памяти сравнительно небольшого объема.

VPN/Network Utility Server

Виртуальная частная сеть (VPN - Virtual Private Network) - это расширение сети, содержащее инкапсулированные, зашифрованные и проверенные на подлинность каналы, использующие общие и публичные сети.

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

Terminal Server

К терминальному серверу требования перечисляются "дополнительно" по отношению к файловому серверу и серверу БД. В настоящее время коэффициент загрузки персональных компьютеров, установленных в локальной сети, не превышает несколько процентов (в пределах рабочего дня), однако потребность использования в процессе работы современного ПО приводит к необходимости регулярной (1 раз в 3 года) замены ПК. Мириться с настолько низким КПД покупаемого оборудования не хочется, поэтому в последние годы все большую популярность приобретают так называемые терминальные системы, в которых выполнение программ сосредоточено на выделенных для этой цели серверах. Это позволяет, с одной стороны, заметно увеличить срок эксплуатации имеющегося оборудования, а с другой - предоставить пользователям при необходимости доступ к весьма значительным ресурсам. При низкой производительности системы в отличие от системы с локальным исполнением замена устройств абсолютно не требуется, достаточно просто добавить еще один сервер и перенести на него часть клиентов. В таком случае все оборудование эксплуатируется до полного физического износа.

Терминальный сервер, в общем, ничем не отличается от обычного - например, сервера БД. Единственной его особенностью являются повышенные требования к пропускной способности сетевого интерфейса при пересылке коротких пакетов - это естественно, так как 90% пакетов, отсылаемых терминальным сервером, имеют длину 100-200 байт. Такое положение дел приводит к тому, что зачастую четыре сетевых адаптера с полосой пропускания 100 Mbps показывают в случае терминального сервера производительность большую, нежели один адаптер с полосой пропускания 1 Gbps. При конфигурировании терминального сервера обращают внимание на: пропускную способность памяти при произвольной выборке, размер и иерархию кэш-памяти процессоров (весьма важно в ситуации постоянного переключения десятков пользовательских процессов), скорость работы системы виртуальной памяти (которую, как и каталог временных файлов, возможно, имеет смысл размещать на дисковых накопителях, не входящих в отказоустойчивый массив, чтобы не "упираться" в производительность его контроллера) и, наконец, на операционную систему. Частным случаем терминального сервера можно признать работу нагруженного Web-сервера, выполняющего одновременно значительное число приложений (CGI, Perl и т. д.).

Web Caching Server

Web-кэш располагается между Web-сервером(-ми) и клиентом(-ми) и отслеживает запросы HTML-страниц, картинок, файлов (все это объединяется общим понятием "объекты"), которые записывает и копирует в себя. Если после этого происходит другой запрос по этим же объектам, нет необходимости опять обращаться непосредственно к удаленному серверу - данные просто передаются из кэша. Существуют две основные причины, по которым целесообразно использовать Web-кэширование:

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

Одним из примеров конкретной реализации Web-кэша может быть кэширующий proxy-сервер, являющийся разновидностью кэша с общим доступом и работающий на тех же принципах, только масштабнее.Поскольку данное устройство обычно обслуживает довольно много клиентов, существует довольно много "хитов" (объектов, запрашиваемых определенным числом клиентов). Нередки случаи 50%-ной и большей эффективности попадания в кэш, что в значительной степени снижает задержки и уменьшает трафик.

Можно признать, что Web Caching Server является разновидностью файлового сервера с запущенной на нем задачей-маршрутизатором, когда для каждого поступающего запроса определяются источник данных, диск сервера или внешний интерфейс. Предъявляются те же требования, что и к файловому серверу, но с небольшим дополнением: процессорная мощность (на самом деле небольшая) должна быть достаточной для задачи сравнения данных. Требования к надежности систем хранения можно резко снизить, выгадав при этом в производительности и/или цене. Однако объем, отводимый для кэшируемых данных, должен быть максимально большим.

"Толстый" и "тонкий"

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

Проектирование серверного парка стоит начинать с анализа предполагаемых прикладных задач и последующего выяснения сравнительных достоинств мощного универсального сервера и набора нескольких специализированных, имеющих "функциональный" уклон серверов. Перспективность решений всегда зависит от динамики роста количества задач, их разнообразия и объемов. Они же задают требования к надежности и масштабируемости (scalability). Того и другого никогда не бывает много, однако не мешает поинтересоваться ценой и целесообразностью их достижения. Определенно, колоссальная популярность платформы х86 открытой архитектуры породила миф о "масштабируемости" - стойкое заблуждение по поводу необыкновенных возможностей модернизации оборудования. "Вечной иглы для примуса" (т. е. сервера) так же не существует, как и для прочей компьютерной техники. Достаточно беглого взгляда, чтобы понять: предлагаемые на рынке процессоры уже нельзя установить в ваш сервер, купленный, казалось бы, недавно, как нельзя найти память EDO ECC или кэш-модули для RAID-контроллера. Сомнительна и экономическая целесообразность постоянной замены одних компонентов на другие по мере их появления на рынке с целью поддержания актуальности платформы. У серверов тоже нет "иммунитета от будущего", и самое дорогостоящее универсальное решение с огромным запасом производительности может оказаться бессильным перед лицом очередного нового стандарта. За что мы в таком случае платим?

Открытая архитектура PC породила отношение к масштабируемости как к творчеству на уровне узлов и компонентов. За 20 лет ее существования поменялось немало стандартов, интеграция привела к тому, что многие, выполнявшиеся выносными контроллерами функции, теперь реализованы в базовой логике системных плат. PC стягивается в "точку", однако логика пользователей, работающих c x86-cовместимым оборудованием, не изменилась: "завтра мы поставим более мощный процессор, потом добавим память, потом поменяем диски на более скоростные, а потом... все это выбросим и нафаршируем старый ящик новым хламом". Масштабируемость и модульность в современном понимании (пропагандируемом прежде всего Intel) - это построение аппаратных комплексов, минимальные единицы которых - не процессорные модули и модули памяти, а компактные устройства различной специализации в архитектуре х86 для совместного или раздельного выполнения используемых на практике типов приложений.

Индустриальный стандарт для реализации модульного построения ИС предприятия давно существует - это 19-дюймовые шкафы-стойки (rackmount). 19" (482,6 мм) - размер, измеряемый по передней стенке устройства (с учетом крепежных комплектов): сервера, сетевого концентратора или коммутатора, источника бесперебойного питания.

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