Сервера описание: Серверы : типы серверов, классификация

Серверы : типы серверов, классификация

Содежание:

Сервер рабочей группы
Сервер контроллер домена
Прокси Сервер
Сервер электронной почты
Веб сервер
Терминальный сервер
Сервер баз данных
Файловый сервер
Серверы приложений
Брандмауэры
Серверы DHCP
Серверы FTP
Принт-серверы
Домашний сервер
Сервера 2012

1. Что такое сервер?
2. Какие существуют типы сервеов?
3. Какими свойствами они обладают?
4. Чем сервер отличается от рабочей станции?
5. Каким требованиям должен соответствовать сервер?
6. Почему необходимо установить сервер, а не мощный ПК?

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

В соответствии со специализацией компьютеров появляются и специальные требования к вычислительной технике: офисный компьютер должен быть компактным и бесшумным с посредственной производительностью, домашний игровой компьютер должен иметь достаточную производительность и способность качественно воспроизвести медиа данные, иметь достаточно интерфейсов для подключения дополнительных устройств. Графическая станция должна иметь возможность воспроизвести, к примеру, 3D проект изделия с высоким разрешением, а рабочая станция иметь общую высокую производительность для выполнения ресурсоёмких приложений.
Всё это в теории. В реальной жизни, происходит пересечение границ требований и возможностей компьютеров, неизменным остается одно — это устройства персональные, т.е. четко прослеживается связь один человек — один компьютер.
А что же есть сервер? Это конечно же тоже компьютер, но предназначенный для решения более масштабных задач, или более требовательных к ресурсам программ (1С предприятие, базы данных и т.д.) По назначению серверы подразделяются на типы, виды, классы, все зависит от того, какая задача возложена на конкретный сервер. МОжете почитать статью о том как подобрать конфигурацию сервера для 1С.

Итак дадим определение серверу:

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

В зависимости от задач и условий использования, сервер имеет следующие основные свойства:

— Производительность
— Надежность
— Масштабируемость
— Управляемость

Разберем в вкратце характеристики серверов.

Производительность. Основной показатель мощности.

Производительность зависит от «начинки» сервера, то есть сколько процессоров, сколько ядер в каждом процессоре, обьем оперативной памяти… В общем все так же как и у домашнего ПК, чем производительнее его комплектующие, тем он работает шустрее.
В отличии от домашнего компьютера в серверах применяются более мощные компоненты, продвинутые технологии, такие как, например: использование 4х процессоров на одной материнской плате, двух и четырехканальный режим работы оперативной памяти, применение жестких дисков с интерфейсом SAS (Serial Attached SCSI) частота вращения шпинделя которого 15 000 оборотов/мин, имеются независимые шины PCI-e x16 для производительных RAID и HBA контроллеров. Это лишь часть того что я привел к примеру. Подробной информации гораздо больше, ее хватит на отдельную статью.

Надежность

Надежность это показатель сервера, выделяющего его от обычного компьютера. Чем ? к примеру многие говорят, или думают «зачем покупать дорогой сервер, когда его можно собрать из простых комплектующих для домашнего компьютера ?» Да, безусловно можно назначить роль сервера обычному десктопному компьютеру. Многим маленькие фирмы так и делают. Но. Конечно же, есть НО! Стоит задуматься почему же сервер в отличии от простого компьютера так дорого стоит. Просто от того что рассчитан он на более долгое время службы. И изначально в серверную платформу (материнская плата + процессор + память + дисковый массив) закладываются разработки увеличивающие долговечность и надежность данной машины. Надежность не только в отношении того что он будет работать и не зависать, глючить и тормозить, что часто бывает с домашним компьютером. В него заложено два вида надежности, это:

1. Физическая надежность – стабильность работы достигаемая надежными комплектующими и качественной сборкой в целом.
2. Аппаратная надежность – отсутствие программных сбоев за счет стабильности работы аппаратной части.

Возьмем к примеру технологию Коррекция ошибок памяти – ECC, эта технология имеет не совсем понятное простому пользователю определение, и приводить его я не стану, объясню проще: эта «штука» позволяет предотвращать появление сбоев в работе памяти, (при записи и чтении внутри чипов памяти), из за таких сбоев операционная система может просто замереть, зависнуть, в случае с операционной системой windows мы можем получить синий экран. Эти ошибки крайне редко возникают в обычной памяти компьютера (не имеющий ECC) и в крайнем случае, случись такой сбой на вашем компьютере вы просто перегружаете систему и работаете, или играете дальше.
Чем опасна ошибка, возникающая в памяти, или любой аппаратный «тормоз» во время работы сервера, например базы данных. Что вообще такое база данных, сейчас спросите вы. Объясню просто и коротко. Это набор из сотен и тысяч таблиц, хранящихся в одном большом и структурированном файле. За работу с этим файлом отвечает приложение базы данных, например mySql, Ms SQL server и тому подобные. Во время работы приложения осуществляющего обработку (запись и чтение) в таблицах базы данных, все эти данные проходят через оперативную память. И случись такой сбой, есть не малая вероятность того, что файл базы данных будет поврежден. И программа об этом и сообщит, что невозможно открыть файл БД, или в файле БД обнаружена ошибка. Есть, конечно вероятность «поднять» эту базу, с помощью программ. Но это все время простоя и также вероятность потери данных. Это тоже так, в краткой форме о надежности среды базы данных… Для повышения надежности и сохранности базы данных еще производиться резервирование базы данных, об этом можно почитать здесь.
Еще есть такая, применяемая в серверах память, FB-DIMM — Full Buffered Dual Inline Memory Module –тип модулей памяти, идущий на смену буферизованной памяти в серверах и других системах, требующих большого объёма оперативной памяти в сочетании повышенной надёжностью.

Разъёмы модулей и слотов FB-DIMM механически аналогичны 240-pin модулям и слотам DDR2, но абсолютно несовместимы c «обычными», использующими тот же тип разъёма DDR2 модулями памяти.
Это объясняется тем, что из 240 контактов FB-DIMM использует только 96, уменьшенное количество используемых контактов стало возможным благодаря использованию высокоскоростного последовательного интерфейса — передача данных от контроллера к модулю осуществляется по 10 дифференциальным парам, а обратно – по 12 или 14. Это облегчает создание контроллеров памяти с большим числом каналов, вплоть до 6, что резко улучшает производительность и масштабируемость.
Для того, чтобы подключить установленные на модуле FB-DIMM обычные DDR2 микросхемы к высокоскоростному последовательному интерфейсу, каждый модуль FB-DIMM содержит микросхему Advanced Memory Buffer (AMB), которая осуществляет высокоскоростную буферизацию и конверсию всех сигналов, в том числе и передачи адреса, а не только данных, как у обычной буферизованной памяти.
То есть, чипы памяти работают не напрямую с контроллером памяти на материнской плате, а через промежуточный буфер.

Один канал FB-DIMM допускает установку до восьми модулей, что значительно увеличивает максимальный объём оперативной памяти (учитывая возросшее число каналов, теперь возможно спроектировать материнскую плату, поддерживающую 48 модулей памяти суммарным объёмом 192Гб).
В равных условиях (одинаковая частота микросхем и число каналов) производительность памяти типа DDR2 FB-DIMM ниже чем у буферизованной DDR2, и тем более, чем у «обычной» небуферизованой DDR2 в силу того, что микросхема буферизации сигналов AMB вносит дополнительные задержки (собственно на буферизацию) при передаче команд и данных между микросхемами памяти и контроллером.

Однако технология FB-DIMM позволяет при сравнимой стоимости материнской платы и чипсета развести большее количество каналов памяти, что в ряде ситуаций позволяет значительно поднять производительность системы в целом, несмотря на увеличенные задержки. Кроме того, контроллеры памяти FB-DIMM способны обращаться к каждому каналу отдельно в произвольный момент времени (независимо от загруженности остальных каналов), что также повышает производительность.
Память FB-DIMM вряд ли найдет применение в настольных компьютерах и ноутбуках, так как основные её преимущества сводятся к возможности установки большого числа модулей, но при этом сами модули дороже в силу наличия микросхемы AMB и обладают меньшей производительностью.
Данный тип памяти как нам теперь известно, не совместим с простой DDR2, и в магазинах найти в наличии очень сложно. Такие модули привозят от поставщиков только под заказ.

Далее рассмотрим еще одну «фишку» применяемую в серверах: это RAID массивы.
Рэйд массив это: в переводе с английского «RAID» (Redundant Arrays of Inexpensive Disks) означает «избыточный массив независимых дисков». Перевод не дословный, точно отражающий смысл. Впервые термин RAID появился в 1987 году, когда исследователям из Калифорнийского Университета в Беркли удалось создать действующий массив из нескольких жестких дисков.

Дисковый массив — несколько накопителей, централизованно управляемых и настраиваемых.
Первоначальное назначение RAID массива – создание из нескольких жестких дисков -одного диска большого объема и с увеличенной скоростью доступа. Затем массивы стали выполнять функцию сохранения данных, на случай выхода из строя одного или нескольких жестких дисков входящих в рэйд массив. Именно эти особенности (увеличенный оббьем, повышенная скорость чтения/записи, надежность хранения данных) сделали RAID-массивы востребованными в бизнесе. Для быстрой работы с обьемныйми базами данных RAID массив просто уникальное и незаменимое решение.
Со временем оборудование для построения RAID массивов стало более доступным, особенно с появлением дешевых решений для IDE/ATA и SATA дисков. Проще выражаясь, раньше RAID можно было собрать, имея только специализированные контроллеры и жесткие диски, а сейчас на любой материнской плате комплектации PRO имеются контроллеры поддерживающие RAID режим для накопителей. Более детально в типы рейд массивов я залезать в этой статье не стану.

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

Следующий пункт — источник питания.

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

Основное отличие серверного блока питания от блока питания обычного домашнего компьютера в том что он изначально спроектирован как надежный источник питания, разработан для круглосуточной бесперебойной работы в течении длительного времени. (как минимум точно отработает то количество часов заявленное производителем)
В плане параметров стабилизации выходных напряжений и защиты от помех выходного напряжения, к серверным блокам питания предъявляются повышенные требования. Блоки питания серверов снабжены высококачественными высокопроизводительными вентиляторами на шарикоподшипниках, которые гарантируют продолжительное время наработки на отказ. Так же для увеличения срока службы в схемах используются конденсаторы без электролита Японского производства, с учетом всех этих пунктов срок службы эксплуатации составит около 5 лет.
В серверах также применяют дублированное питание, это значит что в корпусе сервера установлено два блока питания, и в случае выхода из строя одного, не останавливая работы контроллер питания переключит на второй, исправный блок питания. А неисправный можно заменить, опять же не останавливая работу сервера.

Масштабируемость

Масштабируемость — это возможность увеличить вычислительную мощность сервера или операционной системы (в частности, их способности выполнять больше операций или транзакций за определенный период времени, либо запускать больше различных служб) за счет установки большего числа процессоров, оперативной памяти и т.д. или их замены на более производительные.
Это есть масштабируемость аппаратная.
Изначально сервера в продаже идут в базовой комплектации, но с заложенным потенциалом к «апгрейду» — аппаратная масштабируемость. К примеру базовый набор сервера имеет один процессор, два модуля памяти (в серверах всегда используются только парные модули памяти) например 2х2 гб и дисковый массив из двух жестких дисков допустим 146 гб. Далее (или сразу) по мере потребности можно доустановить еще один процессор, память или добавить диски в массив.

Масштабируемость программная.
За эти расширения функционала (служб) уже отвечает программное обеспечение, то есть серверная операционная система, самая распространенная это, конечно же, MS Windows Server 2003/2008.

Управляемость сервера

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

Классификация серверов – по назначению, выполняемым функциям или ролям.

Сервер рабочей группы.

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

Сервер контроллер домена, Domain Controller server.

Необходим в организации с количеством сотрудников более 20 рабочих мест, позволяет централизованно управлять сетевыми и файловыми ресурсами компании, также обычно выполняет роль сервера печати. DC server должен быть уже на порядок качественнее и надежнее в отличии от сервера рабочей группы, иметь возможность масштабирования при росте количества пользователей локальной сети. Производительность его зависит от масштаба компании, обычно это одно- двухпроцессорный узел, под управлением MS Windows Server 2003-2008 с настроенной службой каталогов Active Directory.

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

Сервер электронной почты. Mail Server.

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

Веб сервер, сервер web приложений.

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

Терминальный сервер.

Работу удаленных офисов, мобильных пользователей и сотрудников, часто работающих из дома или в командировке, с обеспечением привычного доступа к рабочим ресурсам посредством сети Интернет или выделенных каналов связи способен обеспечить терминальный сервер. Шифрование передаваемых данных обеспечивает безопасность такого вида связи. Пользователь соединяется через канал связи с сервером, вводит свои учетные данные и попадает на свой виртуальный рабочий стол, или документам. Эта служба удобна тем что важные данные хранятся непосредственно на сервере, и доступ к ним можно получить из любой точки мира, был бы там лишь доступ в интернет! Также позволяет использовать программу 1С удаленно из любой точки планеты, при налифии интернет канала.

Сервер баз данных. Database server.

Следующая роль следует из названия — обработка данных, организованных и структурированных согласно определенным правилам и хранимых совместно. Наиболее часто используемые средства управления данными это MS SQL Server, Oracle, Apache, MySql. В случае потребности бизнес процессов компании в подготовке и обработке данных необходим выделенный вычислительный ресурс. Как правило, параметры такого узла напрямую зависят от масштаба базы данных, количества пользователей, динамики и характера обращений к данным. Важность бизнес приложения связанного с обработкой данных в жизни компании определяет необходимый уровень доступности данных, т.е. отказоустойчивости и надежности такой системы.

Файловый сервер.

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

Серверы приложений.

Для сервера приложений характерны расширенные возможности обработки информации, а взаимодействие с клиентом становится подобным работе приложения. В маркетинге термином «сервер приложений» обычно обозначают предлагаемое продавцами комплексное решение, которое содержит все требуемые компоненты технологий. Для некоторых организаций такой комплексный подход к построению сервера приложений облегчает разработку благодаря унификации разрабатываемых моделей и централизации поддержки.
«Беспроводной» сервер
В своей простейшей интерпретации такой компьютер может представлять собой типичный Web-сервер или сервер приложений, который просто знает, как передавать документы, составленные на стандартном для беспроводных устройств языке. Часто в качестве такого языка выступает Wireless Markup Language (WML). Адаптация Web-сервера для работы в качестве беспроводного сервера, способного обрабатывать документы WML-типа, обычно сводится просто к тому, чтобы обучить сервер распознаванию этих документов. Web-серверу требуется только сообщить клиенту, что документ составлен в формате для беспроводных устройств, и на этом его работа заканчивается.

Брандмауэры, файрволлы.

Опять заморские выражения, если еще не знаете что это давайте по-русски. Это защитный экран от вредоносных воздействий из интернета, стена в одну строну пропускает исходящие данные, а в обратную (на прием) уже анализирует что именно поступает в сеть, определяя вредоносные данные, отсеивает их из общего потока входящей информации, что в настоящем времени является очень актуальной защитой от вирусов и атак из интернета.
Прокси-серверы можно сконфигурировать так, что они будут принимать или отвергать определенные типы сетевых запросов, поступающие как из локальной сети, так и из Интернета. В такой конфигурации прокси-сервер становится межсетевым экраном — брандмауэром. Брандмауэр, как и подразумевает его «боевое» имя, представляет собой средство обеспечения безопасности, задачи которого во многом схожи с работой пограничников: осматривать каждый фрагмент данных, который пытается пересечь границу сети.

Серверы DHCP

В настоящее время во многих локальных сетях (интрасетях) также используется протокол TCP/IP, но иногда применяются и оригинальные протоколы обмена, такие, как NetBEUI или AppleTalk. IP-адрес компьютерам можно присваивать вручную, или же на одной из машин запускается так называемый сервер DHCP (Dynamic Host Configuration Protocol), который автоматически присваивает IP-адрес каждой локальной машине. Основное преимущество сервера DHCP — свобода изменения конфигурации локальной сети при ее расширении, добавлении или удалении машин (например, портативных ПК).

Серверы FTP

Подобные серверы, работающие на основе протокола File Transfer Protocol, уже много десятилетий назад стали стандартом де-факто при перемещении файлов в Интернете. FTP-серверы поддерживают работу простых файловых менеджеров — клиентов. Сложные FTP-серверы обеспечивают администратору большие возможности управления в том, что касается прав на подключение и совместного использования файлов, типов разделяемых файлов и их размещения. Конфигурируемые ресурсы, выделяемые ряду соединений с сервером, ограничения на количество передаваемых данных и минимальную скорость передачи и т.п., становятся все более популярными средствами, помогающими повысить безопасность FTP-серверов.

Принт-серверы

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

Домашний сервер

В связи с тем, что компьютерная техника имеет очень доступную цену, и проникает повсюду, а также современные операционные системы имеют серверные возможности. С их помощью можно предоставлять пользователям других (соседних) компьютеров доступ к данным на жестком диске или к принтеру, а также «делиться» каналом интернета. Кроме того, домашний сервер можно использовать для резервного хранения данных или, сделав его доступным через Интернет, работать с документами на нем с любого ПК, подключенного к глобальной Сети.
«Поднять» домашний сервер для хранения файлов и разделения доступа к Интернету не так сложно, как может показаться неискушенному пользователю. Для этой цели можно использовать обычный компьютер, даже без монитора.
Для файлового или простого веб-сервера достаточно компьютера с процессором не слабее Intell Pentium 4 или AMD Sempron, оперативной памятью объемом 512 Мб и приводом CD-ROM. Если же на компьютере планируется запуск игрового сервера (весьма популярная инициатива в небольших локальных сетях), потребуется машина помощнее.

история возникновения, определение, предъявляемые требования, описание основных подсистем.

Чтобы лучше понять, что такое современные серверы, кратко рассмотрим историю их возникновения. Изначально, вся электронная обработка данных проходила на мощных ЭВМ – мейнфреймах, у пользователей был лишь терминал для доступа к данным. Мейнфреймы (mainframe — основная стойка (англ.)) представляли собой мощные, универсальные ЭВМ для одновременного обслуживания нескольких тысяч пользователей. Главная особенность их архитектуры — сбалансированность, что достигалось с помощью дополнительного процессора на уровне канала, который синхронизируется с вычислительным процессором по прерываниям. Обращаясь к канальному процессору за данными, вычислительный процессор в это время переключался на расчеты для параллельных задач. Терминал представлял собой алфавитно-цифровой дисплей и клавиатуру, которые подключались к мейнфрейму. Мейнфреймы поставляли несколько компаний: Hitachi, Amdahl, IBM и др. Как правило, их продукция была несовместима между собой.

Компании были замкнуты на решения одного поставщика, который поставлял все аппаратное и программное обеспечение. Компьютерные системы были очень дорогими, а переход с одной системы на другую был очень болезненным. В 1971 г. компанией Intel был разработан первый микропроцессор (i4004), что сделало возможным появление персонального компьютера — IBM PC. С ростом мощности и количества ПК произошел постепенный переход от централизованной обработки информации к распределенной (на ПК). Терминалы стали замещаться ПК, а от мэйнфреймов постепенно отказались.

Однако с ростом количества ПК и их мощности, развитием локальных сетей, вновь возникла потребность в централизованном хранении и обработке данных.

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

Изначально распространение получили файловые серверы, где пользователи хранили свои данные и обменивались ими. С ростом глобальной компьютерной сети Интернет возникло новое направление — телекоммуникационные серверы (веб серверы, ftp, доменных имен, почтовые). С развитием СУБД, в силу изменения формата хранения и доступа к данным, файловые серверы утратили свою популярность, и их во многом заменили серверы баз данных. Файловые серверы остаются и по сей день, но они приобрели второстепенное значение — их используют лишь для хранения пользовательских файлов и различных архивов. В последнее время выросла популярность терминальных серверов — ПК пользователей служат лишь терминалом для отображения и ввода данных, а все пользовательские задачи выполняются на сервере. Таким образом достигается значительная экономия на ПК (на роль терминала годятся даже маломощные компьютеры), снижаются затраты на установку и поддержку программного обеспечения, решаются вопросы конфиденциальности и сохранности данных.

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

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

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

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

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

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

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

Наихудший вариант — простой, сопровождающийся потерей данных. Зачастую, данные могут стоить дороже, чем самый современный сервер. Чтобы предотвратить данную ситуацию, необходим постоянный бэкап данных на ленточные накопители или другие устройства хранения-CDRW, DVD-RW и др.

В 1995 г. компанией Intel, лидирующим поставщиком микропроцессоров, был разработан процессор Pentium Pro (150МГц, 512Кб кэш), позиционирующийся как серверный. Он отличался от десктопных аналогов большим кэшем и продвинутой архитектурой, частично заимствованной у процессоров с архитектурой RISC. В Pentium Pro Intel впервые включил технологию динамического исполнения (Dynamic Execution), то есть инструкции могут исполняться не только последовательно, но и параллельно с помощью предсказания ветвей кода и переупорядоченного исполнения инструкций. Тем самым значительно повысилась эффективность процессора — количество команд, выполняемых за такт.

Вторым нововведением стал большой встроенный кэш L2. Для серверных систем наличие большего кэша является очень важным. Процессоры всегда работают на частотах в несколько раз превышающих частоту памяти. Половина инструкций стандартных приложений представляет собой команды работы с памятью — загрузку и выгрузку данных (Load-Store). Работа с памятью происходит по следующей схеме: если данные не были найдены в кэше L1, то следует обращение к кэшу L2, на это уходит 9–16 процессорных циклов, если данных нет и в кэше L2, то на обращение к памяти уходит до 150 процессорных циклов, в течение которых процессор ждет данные. Большой кэш L2 повышает вероятность быстрого доступа к данным, следовательно, увеличивает эффективность работы процессора.

Можно говорить о том, что Intel впервые применяет и обкатывает свои новые продвинутые технологии именно на серверных процессорах, потом эти технологии постепенно распространяются и на десктопы. Это уже произошло с интегрированным кэшем L2, динамическим исполнением, многопоточностью (hyper-threading). На очереди 64 битная адресация памяти (ЕM64Т).

За Pentium Pro последовали другие серверные процессоры: в 1998 г. — Intel Pentium II Xeon (400–450МГц, 1-2Мб кэш), Pentium III Xeon (700–900Мгц, 1-2Мб кэш). В 2001 г. был выпущен серверный аналог Pentium 4, Хeon, который развивается и используется и в настоящее время.

Таким образом, Intel уже 9 лет разрабатывает серверные процессоры и материнские платы. С 1999 г. Intel, чтобы расширить свой серверный бизнес, начала разрабатывать и производить серверные корпуса, а в 2001 г. впервые самостоятельно разработала серверный чипсет — E7500. До этого Intel и другие производители серверных материнских плат использовали серверные чипсеты фирмы ServerWorks (отделение компании Broadcom). С появление чипсетов E7500 и E7501 Intel практически полностью вытеснила ServerWorks с рынка двухпроцессорных чипсетов. Сегодня чипсеты ServerWorks широко используются только в многопроцессорных системах на Xeon MP.

Современные чипсеты Intel условно можно разделить на серверные и десктопные. В серверных чипсетах шины ввода-вывода PCI-X напрямую соединены с MCH (Memory Controller Hub), в десктопных это всегда делается через южный мост (ICH-I/O controller HUB). В чипсетах для серверов начального уровня (E7210, 875P) гигабитный адаптер Ethernet напрямую подключен к MCH, чтобы сбалансировать нагрузку и разгрузить ICH.

Рисунок 1. Сравнение архитектуры чипсетов для двухпроцессорных серверов (E7500), однопроцессорных серверов начального уровня (E7210) и десктопных чипсетов Intel (I845).

К настоящему времени серверные решения от Intel достигли степени зрелости: появились общепринятые открытые стандарты на отдельные серверные подсистемы: IPMI (удаленное управление), SSI (блоки питания и корпуса), DMI (управление и инвентаризация системы).

Теперь рассмотрим основные требования, предъявляемые к серверу, сложившиеся на данный момент:

1. Надежность
2. Быстродействие
3. Управляемость
4. Расширяемость

1. Надежность

Благодаря чему в серверах достигается надежность:

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

2. Быстродействие

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

Рассмотрим самые распространенные серверные роли и нагрузки на различные подсистемы в ходе их выполнения:

Таблица 1. Условные уровни нагрузки на различные серверные подсистемы в зависимости от роли сервера. (1-наименьшая нагрузка, 3-наибольшая.)

Таким образом, мы можем выявить три серверных задачи, где процессорной мощности современного офисного компьютера может быть достаточно:

• файл-серверы
• файрволы
• почтовые серверы

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

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

Пропускная способность «десктопной» шины PCI — 133 Mб/c., что легко «съедается» устройствами ввода-вывода.

Гигабитная сетевая карта имеет максимальную пропускную способность в 125 Мб/c., соответственно, две гигабитных карты, работающие одновременно, дадут уже 250 Мб/c. Если сюда приплюсовать еще и трафик от винчестеров — в случае IDE до 40–60 Мб/c., SCSI до 60–70 Мб/c. Если используется RAID контроллер с несколькими винчестерами в массиве, то трафик по шине увеличится пропорционально их количеству. Причем сервер должен обслуживать весь этот трафик одновременно. Как мы уже выяснили ранее, десктопные чипсеты имеют одну общую шину ввода-вывода, таким образом, картам расширения приходится конкурировать за пропускную способность шины, которая становится «узким местом». В свою очередь для сервера характерно наличие нескольких независимых «широких» шин ввода-вывода, сейчас это PCI-X, в будущем PCI Express.

Итак, быстродействие в настоящем сервере обеспечивается следующим образом:

• Использование двух и более процессоров
• Наличие несколько независимых шин PCI-X или PCI Express
• Возможность использования больших объемов оперативной памяти

3. Управляемость.

• Возможность удаленно (по сети) получать информацию о температуре процессоров, материнской платы; скорости вращения вентиляторов.
• Администратор может устанавливать различные варианты получения предупреждений (по электронной почте, на пейджер, SNMP Alerts), о событиях, происходящих на сервере- остановке вентиляторов, перегреве процессоров, вскрытии шасси и т.д.
• Удаленное включение/выключение, перезагрузки сервера, просмотр журнала событий, диагностика, обновление микрокодов.

4. Расширяемость.

• Возможность использования нескольких процессоров
• Возможность установки большого количества модулей памяти
• Несколько независимых шин: PCI, PCI-X для установки дополнительных карт расширения.

Так, мы можем убедиться, что для выполнения всех четырех требований необходим настоящий, полноценный сервер. Установка в качестве рабочего сервера мощного ПК дает мнимую первоначальную экономию, которая потом «съедается» расходами на его обслуживание и модернизацию.

Таблица 2. Сравнение возможностей ПК, рабочей станции и сервера

Из чего состоит современный сервер: описание основных компонентов и подсистем.

У пользователей часто возникает вопрос — почему серверы стоят гораздо дороже, чем обычные мощные компьютеры? В чем их отличие от офисных ПК и почему настоящие серверы лучше. Ответить на этот вопрос можно лишь описав основные компоненты, «кубики» из которых строится сервер. Попытаемся дать краткое описание основных серверных компонентов и подсистем.

Корпуса.

Существует два основных вида серверных корпусов: стоечные и пьедестальные. Пьедестальные корпуса (pedestal) — стандартные «башни», отличающиеся от корпусов ПК лишь размерами, более емкой корзиной для накопителей и более качественным охлаждением. На сегодняшний день пьедестальные корпуса теряют популярность, их место занимают стоечные корпуса (rackmount). Они предназначены для установки в 19-дюймовую телекоммуникационную стойку или шкаф. Как правило, стоечные корпуса комплектуются рельсами, позволяющими выдвигать серверы для проведения сервисных работ. Такие корпуса занимают меньше места и удобнее в обслуживании. Их высота измеряется в юнитах (U). Один юнит равен 44,5 мм. Самые распространенные размеры стоечных корпусов: 1U, 2U, 4U и 5U.

Блоки питания

Серверные компоненты (процессоры, жесткие диски, материнские платы и др.), в силу своей высокой производительности потребляют больше электроэнергии, чем их аналоги для офисных ПК. Следовательно, для серверов требуются более мощные и надежные источники питания. Серверные процессоры Xeon потребляют до 120 Вт, жесткие диски SCSI до 20 Вт, материнские платы до 40 Вт. Путем несложных подсчетов мы можем прийти к выводу, что минимальная мощность источника питания для однопроцессорных систем должна составлять 300 Вт, для двухпроцессорных — от 400 Вт и выше, в зависимости от конфигурации.

В целях повышения надежности в серверах зачастую используют источники питания с резервированием (redundant). В случае выхода из строя одного источника питания, в действие вступает дополнительный, при этом питание не теряется. Администратору на консоль поступает сообщение об отказе одного из источников, что дает ему возможность оперативно заменить неисправную часть и восстановить резервирование. Соответственно, в данном случае источники питания поддерживают возможность «горячей» замены, без выключения сервера.

Материнские платы

Форм-фактор

В серверных системах используются материнские платы двух форм-факторов: ATX(E-ATX) и SSI. ATX более старый и привычный стандарт, главным образом ориентированный на ПК. Сегодня на его базе создают лишь серверные платы начального уровня. SSI (Server System Infrastructure) — специальный стандарт на серверные компоненты (блоки питания и корпуса), активно продвигаемый Intel. Введение открытого стандарта SSI должно упростить создание новых серверных корпусов и блоков питания, тем самым повлечь за собой уменьшение издержек и конечной цены для пользователя.

Видимое отличие материнских плат двух стандартов заключается в разных разъемах питания: 20-контактный у ATX(E-ATX), и новый 24-контактный у SSI. Отличается также и размер платы — SSI это всегда 12″×13″, ATX- 12″×9,8″, E-ATX-12″×13″. В принципе возможно подключение SSI блока питания к ATX плате и наоборот, через специальные переходники, поскольку разъем SSI фактически представляет собой разъем ATX+дополнительные контакты для 3.3В и 5В.

Поддерживаемые шины ввода-вывода

Одним из факторов, влияющих на цену материнской платы, являются поддерживаемые ею шины. Для плат начального уровня (однопроцессорных) характерно наличие стандартной PCI шины, хотя с выходом нового чипсета Intel E7210, шина PCI-X впервые появилась и на однопроцессорных материнских платах. На более продвинутых (двухпроцессорных) платах существуют несколько независимых шин PCI-X. В будущем (конец 2004–2005 гг.) все серверные платы в обязательном порядке будут использовать новую последовательную шину PCI Express. Действительно, PCI Express несет много преимуществ:

• Повышенная пропускная способность — 200 Мб/c на канал, сертифицированы 1, 2, 4, 8, 16 и 32× канальные варианты разъемов. Шина полнодуплексная, т.е. данные могут передаваться «туда» и «обратно» одновременно, пиковая скорость может достигать 6,4 Гб/c.
• Поддержка режима «горячей» замены карт расширения
• Заложены возможности контроля целостности передаваемых данных (CRC)

Таблица 3. Сравнительные характеристики шин передачи данных

Чипсет

Изначально, рынок серверных чипсетов безраздельно принадлежал компании ServerWorks. Но с выходом Intel Xeon и с выпуском чипсета E7500, лидерство на рынке чипсетов для двухпроцессорных плат перешло к Intel. На данный момент ServerWorks присутствует лишь на рынке 4-х процессорных серверов с чипсетом Grand Champion HE.

На данный момент на рынке двухпроцессорных систем присутствуют два чипсета от Intel: E7501 для серверного сегмента и E7505 для рабочих станций (поддерживает AGP Pro 8x). Анонсированы и скоро поступят в продажу платы на основе новых чипсетов Intel E7520 и E7320. Данные чипсеты поддерживают память DDR-2 (400 МГц) — пиковая пропускная способность увеличивается на 20% и достигает 6,4Гб/c, на 40% снижается энергопотребления по сравнению с памятью DDR. Чипсеты также поддерживают шину PCI Express.

Для построения однопроцессорных систем используются чипсеты Intel 875P и Intel E7210.

Таблица 4. Технические характеристики серверных чипсетов фирмы Intel

Управление

Возможность независимого от операционной системы удаленного мониторинга и управления является исключительно важной для серверов. На сегодняшний день возможно дистанционно (по сети) получать информацию о температуре процессоров, материнской платы; скорости вращения вентиляторов и др. параметрах сервера. Администратор может устанавливать различные варианты получения предупреждений (по E-mail, на Pager, SNMP Alerts), о событиях на сервере: остановке вентиляторов, перегреве процессоров, вскрытие шасси. Существует возможность удаленного включения/выключения, перезагрузки серверов. Причем эти функции доступны даже при выключенном сервере, если он подключен к локальной сети или специальной сети управления, и на него подается дежурное напряжение. В будущем, планируется введение дополнительных функций, например, системные администраторы получат возможность удаленно (по сети) получать доступ к экрану и консоли управления сервером, обновлять BIOS и др. функции.

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

Оперативная память

Для серверов характерна поддержка больших объемов памяти. Многие приложения (SQL-серверы, веб-серверы и др.) для ускорения операций подгружают максимальный объем данных в оперативную память. У файловых серверов в оперативной памяти размещается файловый кэш, ускоряющий доступ к данным пользователя. У терминал серверов на основе Windows на каждую пользовательскую сессию отводится как минимум 32 Мб оперативной памяти плюс 256 Mb на операционную систему. Нетрудно подсчитать, что для функционирования терминал-сервера на 50 пользователей необходимо, как минимум, 2 гигабайта памяти. Обычно на двухпроцессорных платах присутствуют от 4-х до 8 разъемов для модулей памяти. Соответственно, максимальный объем может достигать 16 Гб. Хотя на практике, использование более 4-х Гб памяти на 32-битных системах не оптимально. С помощью технологии Physical Address Extensions (PAE) в 32-битных системах можно использовать до 64 Гб памяти, но с потерями быстродействия.

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

Процессоры

Для построения 32-битных однопроцессорных систем сегодня используется Intel Pentium 4, для двухпроцессорных — Xeon DP, для четырехпроцессорных и более — Xeon MP. Фактически Intel Xeon представляет собой Intel Pentium 4, но с включенным блоком многопроцессорности (SMP). Xeon DP на основе 130-нм технологии поддерживает 533 шину, кэш L2 512Кб и L3 1,2 Мб. Недавно появившийся Xeon DP на основе 90 нм. тех. процесса (Nocona) поддерживает 800 МГц шину, кэш L2 1 Мб. Xeon DP (Nocona) поддерживает технологию EM64T, одной из особенностей которой является режим 64-разрядной адресации, который упрощает работу с большими объемами оперативной памяти. В новом Хeon появилась расширенная технология SpeedStep, позволяющая динамически управлять мощностью и сокращать энергопотребление процессора.

Xeon MP отличается от Xeon DP большим встроенным кэшем L3 (до 4Мб), использованием более медленной 400МГц шины и поддержкой 4-x и более процессоров. У процессоров Xeon есть кэши трех уровней L1, L2 и L3. Кэши работают на частоте ядра, но имеют разную задержку работы (латентность): L1 — 2–9 процессорных циклов (в зависимости от типа данных), L2 — +7 циклов (9–16), L3 — +14 циклов (23–30). Фактически, по данным различных исследований, наличие кэша L3 заметно не повышает быстродействия системы на типичных задачах. Особенность кэша процессоров Xeon — инклюзивность, то есть содержимое кэша L1 содержится в L2 и L3, данные из L2 продублированы в L3, что уменьшает эффективную суммарную емкость кэша. Таким образом, для достижения наивысшей вычислительной производительности процессора в первую очередь стоит ориентироваться на частоту шины процессора и на размер кэша разных уровней (большой кэш L2 предпочтительней, чем дополнительный L3, из-за более низкой латентности).

Дисковая подсистема

Диски

На сегодняшний день на рынке представлены жесткие диски трех интерфейсов: Parallel ATA (IDE), Serial ATA (SATA), SCSI.

Parallel ATA (IDE) является основным интерфейсом для персональных компьютеров. К преимуществам данного интерфейса можно отнести низкую цену за мегабайт информации.

Serial ATA является наследником интерфейса PATA. В новом стандарте была расширена пропускная способность до 150 Мб/с, для подключения дисков используются новые плоские кабели. Стандарт SATA допускает «горячее» подключение накопителей, в нем заложен механизм оптимизации очереди команд внутри контроллера, что значительно ускоряет ввод-вывод. В отличие от интерфейса PATA, в стандарте SATA к одному каналу подключается только одно устройство. Интерфейсы SATA и PATA несовместимы физически, но сторонние фирмы разработали преобразователи интерфейсов.

Интерфейс SCSI традиционно использовался в серверных системах. К его неоспоримым преимуществам следует отнести возможность подсоединения до 15 устройств на один канал, высокую пропускную способность (до 320 Мб/с), технологии арбитража шины, снижающие нагрузку на процессор, оптимизация очереди команд. Данные особенности делают SCSI идеальным интерфейсом для задач, связанных с большим количеством операций ввода-вывода. Жесткие диски с интерфейсом SCSI, как правило, имеют большую скорость вращения шпинделя — 10000 или 15000 оборотов в минуту, что увеличивает скорость поиска и передачи данных. К минусам данного интерфейса можно отнести высокую стоимость хранения (жесткий диск SCSI в три-четыре раза дороже, чем накопители SATA или PATA той же емкости). Физический интерфейс SCSI дисков бывает двух видов: интерфейс SCA 80 контактов (поддерживается «горячая» замена) и 68-ми контактный интерфейс (без горячей замены).

RAID контроллеры

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

• Уровень 0 (striping) — блоки данных последовательно размещаются на нескольких дисках, достигается выигрыш в скорости, но без отказоустойчивости. То есть в случае отказа одного из винчестеров пользователь теряет всю информацию.
• Уровень 1 (mirroring) — диски объединены в пару и являются точной копией друг друга, для данного уровня требуются как минимум два диска. Теряется 50% дискового пространства, но достигается отказоустойчивость
• Уровень 5 (striping with parity) — на дисках размещаются блоки данных плюс контрольная сумма. Причем контрольная сумма оказывается «размазанной» по всем дискам массива. В случае отказа одного из дисков, данные восстанавливаются на основе контрольной суммы на диск замены (hot spare). Для построения массива уровня 5 требуется как минимум три диска. Под контрольные суммы используется дисковое пространство, эквивалентное объему одного из накопителей (в случае n накопителей, суммарный объем дискового пространства равен n-1).
• Уровень 0+1 или 10 (mirroring+striping) — зеркалирование+последовательная блочная запись. Представляет собой две группы зеркальных дисков, запись на которые ведется последовательно блоками. Необходимо, по меньшей мере, 4 диска. Потери дискового пространства 50%. Уровень 10 комбинирует скорость и надежность. Такой массив может продолжать функционирование при отказе половины дисков. Так как контроллеру не надо вычислять контрольные суммы, запись на диски происходит значительно быстрее, чем при уровне 5.

Таким образом, уровень 0 чаще всего используют там, где необходима высокая скорость данных, а сохранность данных неважна, например, нелинейный монтаж видео. Уровень 1 используется там, где требуется сохранить данные без использования сложных аппаратных систем. Как правило, уровень 0 и 1, поддерживают все, даже самые дешевые RAID контроллеры, в том числе и интегрированные на материнской плате. Уровень 5 представляется оптимальным по соотношению надежность/потери дискового пространства. Но для его реализации требуется полноценный RAID контроллер с аппаратным ускорением подсчета контрольных сумм. В силу необходимости подсчета контрольных сумм, данный уровень проигрывает по скорости записи уровню 0+1 (10). Уровень 10 используют там, где нужна высокая надежность и скорость чтения/записи, а потери дискового пространства не являются критичными.

RAID контроллеры различаются по типу используемой шины. Как правило, серьезные решения ориентированы на шину PCI-X, как самую быстродействующую на сегодняшний момент. На платах полноценных RAID контроллеров дополнительно размещают кэш-память; есть варианты с интегрированной и расширяемой памятью. Объем кэш-памяти влияет на производительность массива, но эта зависимость не является линейной.

Существует два режима работы кэша RAID контроллера: Write Through (сквозная запись) и Write Back (обратная). При первом режиме контроллер не дает подтверждения записи, пока данные не попали на диски, при втором достаточно того, чтобы данные попали в кэш. Соответственно, второй режим значительно ускоряет операции записи, но существует опасность потери данных при сбое по питанию. Чтобы решить данную проблему некоторые модели RAID контроллеров, как правило, двухканальные, оснащают еще и встроенной батареей (BBU- Battery Backup Unit). В случае сбоя по питанию или аппаратной перезагрузки, RAID контроллер с батареей успевает сбросить данные из кэша на диски.

Существуют и дешевые RAID-решения, например, Zero Channel Raid (ZCR). RAID контроллер данного типа представляет собой карту расширения, которая преобразует встроенные SCSI каналы на материнской плате в каналы RAID. Как правило, ZCR платы не содержат кэша, в них установлены маломощные процессоры. Использование таких систем оправдано лишь для создания массивов уровня 0 и 1.

Также возможно создание RAID-массива без специального RAID-контроллера, программным путем. Многие современные операционные системы поддерживают такую функцию (Windows 2000 Server, Windows 2003 Server, Redhat Linux 9 и т.д.). Однако скорость работы данного массива будет существенно ниже, чем у аппаратного, поскольку центральный процессор будет загружен в большей степени, особенно это будет заметно при уровне-5. Но главной проблемой является низкая надежность подобного решения – при сбое по питанию часть данных массива неизбежно будет потеряна.

Вместо выводов

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

Страница с описанием серверов проекта » Minecraft.Mix-Servers

Общее описание сервера

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

Список модов установленных на сервере

• Industrial Craft 2
• • Advanced Solar Panels
  • GraviSuite

  ChargePads

• MixMod
• Applied Energistics
• ComboArmors
• NuclearControl
• MoCreatures
• ExtrabiomesXL
• MicroBlock
• IC2 Backpack
• Applied Energistics
• Iron Chest 5.2.8
• Forestry
• BuildCraft 3.4.3

Запрещенные предметы

Общее описание сервера

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

Список модов установленных на сервере

• Industrial Craft 2
• • Advanced Solar Panels
  • GraviSuite
• BuildCraft 3.4.3
• Forestry
• Iron Chest 5.2.8
• Applied Energistics

Запрещенные предметы

• BuildCraft

  Запрещено

  ДВС и Паровой двигатель

• Forestry

  Запрещено

  Все виды сумок

• Industrial Craft2

  Запрещено

  Все виды динамита и бомб

• Industrial Craft2

  Запрещено

  Шахтерский лазер

• Industrial Craft2

  Запрещено

  Воронка

• BuildCraft

  Запрещено

  Карьер

• Forestry

  Запрещено

  Письмо

• Список запрещенных предметов может быть пополнен в любой момент, без внесения изменений на сайте.

Общее описание сервера

Создавая сервера Industrial мы объединили все лучшее, что имеется на серверах Hitech, Technology.

Список модов установленных на сервере

• Industrial Craft 2
• • Advanced Solar Panels
  • GraviSuite
• IC2 Backpack
• Applied Energistics
• Iron Chest 5.2.8
• Forestry
• BuildCraft 3.4.3

Запрещенные предметы

• BuildCraft

  Запрещено

  ДВС и Паровой двигатель

• Forestry

  Запрещено

  Все виды сумок

• Industrial Craft2

  Запрещено

  Все виды динамита и бомб

• Industrial Craft2

  Запрещено

  Шахтерский лазер

• Industrial Craft2

  Запрещено

  Воронка

• BuildCraft

  Запрещено

  Карьер

• Forestry

  Запрещено

  Письмо

• Список запрещенных предметов может быть пополнен в любой момент, без внесения изменений на сайте.

Общее описание сервера

Большое количество различной брони, мобов(в том числе 3 головы дракон), PVP битвы, огромные мечи, сабли, топоры, кувалды и плащи-невидимки не дадут вам заскучать на пропитанном кровью RPG сервере.

Список модов установленных на сервере

• Rpg Inventory
• TheTwilightForest
• Metallurgy 2
• DamageIndicators

Запрещенные предметы

• TwilightForest

  Запрещено

  Рудный магнит

• TwilightForest

  Запрещено

  Саженец большого сумеречного дуба

• TwilightForest

  Запрещено

  Рог

• Список запрещенных предметов может быть пополнен в любой момент, без внесения изменений на сайте.

Архитектура сервера онлайн-игры на примере Skyforge / Блог компании Mail.ru Group / Хабр

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Обзор

• Сервер — это почти два миллиона строк кода на Java. Для соединения с сервером и отображения красивой картинки используется клиент, написанный на C++.
• Свой вклад в серверный код внесли полсотни программистов. Код писался в течение многих лет лучшими специалистами российского «православного» геймдева. В нем собраны все самые удачные идеи со всего мира.
• На текущий момент у нас написано около 5200 автоматических тестов, налажен continuous integration и нагрузочное тестирование с помощью ботов.
• Сервер умеет запускаться и работать на десятках и сотнях серверов, поддерживать игру сотен тысяч человек одновременно. Мы решили отказаться от традиционной для MMO техники шардирования и запустить всех игроков в один большой мир.

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

Сервисная архитектура

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

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

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

Отсюда родилась наша универсальная структура сервера, которая используется в Skyforge:

• Существует пул физических серверов, на которых будет запускаться игра. Этот набор серверов и наше серверное приложение, которое на них запущено, называется Realm.
• На каждом сервере запускается серверное приложение (JVM), называемое ролью. Роли бывают разные: аккаунт-сервер, игровая механика, чат и т.д. Каждая роль берет на себя большой кусок функционала. Некоторые роли существуют в единственном числе, некоторые запускаются в нескольких экземплярах.
• Роль состоит из набора сервисов. Сервис — это обычный поток (thread), который занимается своей, специфичной для него задачей. Примером сервиса может служить сервис авторизации, сервис резервирования имен, балансировщик нагрузки и т.п. Каждый сервис ничего не знает о физическом расположении других сервисов. Они могут быть рядом, а могут быть на другой физической машине. Сервисы взаимодействуют через систему сообщений, которая скрывает от них такого рода подробности.
• Каждый сервис состоит из набора модулей. Модуль — это «кусок функциональности», у которого есть один метод tick(). Примером модуля может быть модуль статистики, модуль исполнения транзакций, модуль синхронизации времени. Вся работа сервиса заключается в том, чтобы в бесконечном цикле поочередно вызывать метод tick() у своих модулей. Один такой цикл называется «кадр сервера». Мы считаем показатель хорошим, если кадр сервера колеблется в пределах от 3 до 20 мс.
• Вся эта структура описывается в XML-файлах. Системе запуска надо просто «скормить» название роли. Она найдет соответствующий файл, запустит все нужные сервисы и отдаст им списки модулей. Сами модули создадутся с помощью java reflection.

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

Основные сервисы

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

• Аккаунт-сервис. Отвечает за авторизацию и подключение новых клиентов.
• Сервер игровой механики. Тут происходит, собственно, сама игра. После прохождения авторизации клиент подключается сюда и тут играет. С другими сервисами клиент напрямую не взаимодействует. Таких сервисов можно и нужно запускать несколько десятков, а то и сотен. Именно эти сервисы несут основную нагрузку.
• Сервисы баз данных. Эти сервисы выполняют операции над данными игровых персонажей, их предметами, деньгами, прогрессом развития. Их обычно запускается несколько штук. Подробнее об архитектуре баз данных можно прочитать в моем прошлом докладе. ( habrahabr.ru/company/mailru/blog/182088 )
• Чат. Занимается роутингом сообщений чата между пользователями.
• Все остальные сервисы. Их несколько десятков, и они обычно не создают сильной нагрузки, поэтому не требуют обособленных серверов.

Сеть

Под словом «сеть» я подразумеваю систему доставки сообщений от одного сервиса к другому или от одного объекта к другому. Исторически так сложилось, что у нас существует сразу две такие системы. Одна основана на сообщениях. Вторая система основана на удаленном вызове процедур (RPC). В Skyforge система сообщений применяется внутри сервиса игровой механики, чтобы послать какое-то сообщение от аватара к мобу, а также для общения клиента и сервера. RPC используется для общения между сервисами.

Сообщения

Все объекты, которые хотят посылать или принимать сообщения, называются абонентами. Каждый абонент регистрируется в общей директории и получает уникальный идентификатор — адрес. Любой, кто хочет послать сообщение какому-либо абоненту, должен указать адреса «откуда» и «куда». Сетевой движок знает, где находится абонент, и доставляет ему сообщение. Сообщение — это Java-объект, у которого есть метод run(). При отправке этот объект сериализуется, прилетает к целевому абоненту, там десериализуется, а затем вызывается метод run() над целевым абонентом.

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

RPC

Удаленный вызов процедур или RPC появился, чтобы решить проблему цепочек сообщений.
Основная идея заключается в использовании кооперативной многозадачности (Coroutine, Fibers). Тому, кто не знаком с это концепцией, для понимания темы советую заглянуть в «Википедию». en.wikipedia.org/wiki/Coroutine.
Сервис, который хочет, чтобы его могли вызывать через удаленный вызов процедур, должен реализовывать специальный интерфейс и зарегистрировать в специальной директории. Тогда любой желающий может попросить директорию дать ему интерфейс этого сервиса, и директория вернет специальный враппер над сервисом. Вызывать сервисы по RPC можно только внутри файбера (coroutin), т.е. специального контекста исполнения, который можно прерывать и возобновлять в точках разрыва. При вызове методов враппера он будет посылать RPC вызовы на удаленный сервис, прерывать текущий файбер в ожидании ответа и возвращать результат, когда удаленный сервер ответит.

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

Подробнее о нашей имплементации файберов можно узнать из лекции Сергея Загурского ( www.youtube.com/watch?v=YWLHELcvNbE ).

Сериализация

Чтобы у нас работала система посылки сообщений и удаленный вызов процедур, нам нужен клиент-серверный протокол и способ сериализации/десериализации объектов. Напомню, что у нас есть необходимость пересылать команды и данные с клиента на сервер, т.е. из C++ в Java и обратно. Для этого мы по Java-классам генерируем их копии в C++, а также генерируем методы для сериализации и десериализации объектов в байтовый поток. Код для сериализации встраивается прямо внутрь классов и обращается к полям класса напрямую. Таким образом, сервер не тратит процессорное время на обход классов с помощью reflection. Все это мы генерируем с помощью самописного плагина для IntelliJ IDEA. Внутрисерверный протокол для общения между сервисами полностью аналогичен клиент-серверному протоколу.

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

Игровая механика

Основной сервис, который был бы вам интересен, это сервис игровой механики. Именно там выполняется весь код, непосредственно связанный с игрой, именно там моделируется весь игровой мир, летают фаерболы и «грабятся корованы».

Карты и балансировка нагрузки

На серверах игровой механики создаются карты, на которых, собственно, находятся игроки, мобы и происходит все веселье. У каждой карты есть лимит на количество игроков, которые могут на ней находиться. Например, лимит может быть равен единице для персональных приключений, 10–30 для групповых активностей и 250 для больших карт. Что происходит, если на карту захочет попасть еще один игрок, когда лимит исчерпан? Тогда будет создана еще одна копия той же самой карты. Игроки с этих карт не будут видеть друг друга, не будут друг другу мешать. Т.е. в каком-нибудь игровом городе могут быть тысячи человек, но там не будет тесно. Такой способ организации игроков называется «каналы».

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

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

Аватары и мобы

Аватар — это персонаж, которым управляет игрок, моб — это монстр, которого игрок убивает. Это весьма разные, но часто очень похожие сущности. И моб, и аватар умеют ходить по карте, у них есть здоровье, они могут использовать заклинания и т.п. Только аватаром управляет игрок, а у моба есть свой мозг. Кроме того, на картах есть множество всяких сундуков, растений и других интерактивных сущностей. Очень часто нужно делать некую функциональность и цеплять ее к разным сущностям. Для этих целей мы используем компонентный подход, собирая игровую сущность из набора функциональностей. Поясню на примере. Допустим, у игрока и моба есть показатель здоровья. В таком случае мы оформляем элемент «здоровье» как отдельный Java-класс, в котором описываем, как здоровье себя ведет: как оно может уменьшаться, как восстанавливаться, какие есть таймеры и т.п. Потом мы просто складываем все функциональности в специальную HashMap внутри сущности и берем ее оттуда по необходимости. Таких компонент у нас существуют сотни, на них собрана половина игровой механики.

Так как серверное приложение очень сложное, неизбежно возникновение ошибок. Нужно сделать так, чтобы возникновение ошибки, даже необработанного NullPointerException, не приводило к падению сервера. Можно ошибку просто залогировать и пойти дальше, но если ошибка возникнет посреди какого-то длинного действия над аватаром, то аватар может оказаться в сломанном и неконсистентном состоянии. Тут нам на помощь приходит концепция под названием «локаль». Локаль — это контекст, внутри которого объекты могут ссылаться друг на друга. Объекты из одной локали не могут ссылаться на объекты из другой. Если из локали вылетает необработанное исключение, то локаль удаляется целиком. Аватары, мобы и другие сущности являются локалями, удаляются целиком и не могут держать ссылок на других аватаров и мобов. Поэтому все взаимодействие между аватарами и мобами идет через систему сообщений, хотя они находятся вместе на одной машине и в теории могли бы держать друг на друга прямую ссылку.

Репликация

Моделировать игровой мир нужно не только на сервере, но и частично на клиенте. Например, клиенту нужно видеть других игроков и мобов, которые находятся рядом с ним. Для этого используется механизм клиент-серверной репликации, когда с сервера клиентам рассылаются обновления окружающего игрового мира. Делается это с помощью генератора кода, который встраивает отсылку обновлений в сеттеры серверных Java-объектов. Вокруг игрока создается круг определенного радиуса, и если кто-то, например другой аватар, попадает в этот круг, он начинает реплицироваться на клиент. С репликацией есть фундаментальная проблема. Если в одном месте столпится N аватаров, то на каждого из них нужно будет посылать N реплик. Таким образом возникает квадратичная зависимость, что ограничивает количество аватаров, которые могут собраться в одном месте. Именно из-за этой фундаментальной квадратичности клиенты всех ММО тормозят в столицах. Мы избегаем этой проблемы, ограничивая количество игроков на карте и распределяя их по каналам.

Ресурсная система

В игре существуют сотни и тысячи заклинаний, предметов, квестов и других подобных сущностей. Как вы, наверное, догадываетесь, программисты не пишут все сотни квестов, это делают геймдизайнеры. Программист разрабатывает один Java-класс квеста, а описания всех квестов с их логикой, задачами и текстами содержатся в XML-файлах, называемых ресурсами. При старте сервера мы загружаем эти ресурсы и на их основе собираем Java-классы с описанием мира. Этими классами уже может пользоваться сервер. Примерно такая же система существует и на стороне клиента, только там ресурсы не грузятся из XML-файлов, а просто загружается заранее созданный «кусок памяти», содержащий все нужные объекты и ссылки между ними. Ресурсных файлов у нас существует несколько сотен тысяч, но их загрузка на сервере занимает около двух минут. На клиенте же все грузится за секунды. Система очень навороченная, поддерживает такие фичи, как прототипы и наследование, вложенные описатели и т.п. Поверх ресурсной системы у нас созданы специализированные программы для редактирования карт и остальных игровых сущностей.

Сервер в действии

Давайте теперь на примерах рассмотрим несколько сценариев того, как работает вся эта система в действии.

Убить собачку

Классический тест, который мы всегда проводим, если сильно изменили инфраструктуру и хотим проверить, что все работает, называется «Убить собачку». Нужно зайти клиентом на сервер и убить там какого-либо моба. Этот тест покрывает практически все основные моменты сервера и служит прекрасным примером для того, чтобы сложить все вышесказанное вместе. Давайте по пунктам разберем, что и как происходит при убиении несчастной собачки. Конечно, некоторые шаги упрощены, но это не критично для понимания.

• Клиент посылает на аккаунт-сервер сообщение: «Хочу войти в игру».
• Аккаунт-сервер запрашивает базу данных, проводит авторизацию и запрашивает у балансировщика карту, на которой игрок был в последний раз.
• Балансировщик выбирает карту из уже загруженных или создает новую на наименее загруженном сервере игровой механики.
• Клиент подключается к той механике, где для него была создана карта. Пока он подключается, для него загружается его аватар.
• Сервер начинает реплицировать все объекты вокруг аватара на клиент. Клиент рисует шикарную картинку и посылает на сервер команды, которые посылает игрок.
• Игрок начинает бегать по карте, а сервер перемещает его по миру и реплицирует изменения окружающей действительности. Игрок находит какого-либо моба и нажимает кнопку «ударить».
• Команда «удар» прилетает на сервер, на сервере выполняется проверка, что удар возможен, и мобу отправляется сообщение о нанесении повреждений.
• Команда «нанести повреждения» отрабатывается на мобе, просчитывает все резисты и другие подобные вещи, потом берет функциональность «здоровье» и списывает какое-то количество.
• Клиенту посылается ответ с подтверждением нанесения урона, клиент рисует удар.

Масштабирование

Давайте зайдем с другой стороны и посмотрим, как сервер ведет себя под нагрузкой.

• 0 клиентов. Если на сервере никого нет, его можно запускать одним приложением с минимальными настройками и без карт. На сервере нет никакой активности, и большую часть времени он простаивает.
• 1 клиент. Для одного клиента приходится создавать карту, мобов, серверные объекты, которые начинают потреблять память и процессорное время для своей жизни.
• 500 клиентов. 500 клиентов обычно уже достаточно много, чтобы процессорного времени одной персоналки не хватало для работы сервера. Приходится запускать realm на нескольких машинах или на более мощных серверах.
• 10000 клиентов. 10000 клиентов требуют уже нескольких серверов. Так как большая часть нагрузки приходится на игровые механики, нужно запускать realm с дополнительными сервисами игровой механики.
• 100000 клиентов. При 100000 одновременных игроков больше половины серверов заняты игровой механикой.
• Клиентов больше, чем железа. Если вдруг игроков станет еще больше, а железо у нас вдруг кончится, то придется ограничивать вход людей в игру, пока подвозят новые серверы. Для этого существует очередь на вход, которая заставляет игроков ждать, когда сервер будет готов их принять. Эта очередь гарантирует, что одновременно один realm не может содержать игроков больше, чем мы готовы принять. В очередь игроков могут начать ставить и в том случае, если из-за бага или еще по каким-либо причинам сервер вдруг стал работать медленнее определенного порога. Лучше сделать приемлемый сервис для ограниченного числа клиентов, чем упасть для всех.

Заключение

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

Ну и конечно же запись на закрытый бета тест. sf.mail.ru

Занятная статистика

Статистика по строкам кода. В статистику включен только сервер.

Авторы, собранные из комментариев к коду.

P.S.: Как обычно, на все вопросы отвечаем в комментариях.

Туториал — [ЧИТАТЬ ВСЕМ!] Какие бывают сервы | Bukkit по-русски

Чтобы не повторять ошибки тысяч собирателей сервов, прочитайте эту памятку.
1. НЕ пытайтесь набить в сервер тысячи модов, которые вам нравятся! Это идиотизм. а. Никому большинство их не нужны. Только поиграться разок, а сервер должен жить месяцами. б. Ни один самый мощный хост не выдержит. Будет куча лагов и багов из-за большого количества и несовместимости модов.
в. Все моды надо настраивать долго и мучительно и за всеми надо следить. Даже если ошибок сначала не будет, потом они могут появиться из-за накопления данных, или из-за того, что игроки влезли не туда.
2. На сервере есть определённый стандартный набор нужных плагинов. Их список вы можете составить сами — приват территорий, сундуков, плагин бана, чата, essentials, falsebook, worldedit, worldborder и т.д. Позднее можно заменять одни плагины другими, исполняющими те же функции.
3. Главное, что должно быть у серва — это определённая тематика! Именно под неё вы подбираете набор плагинов. Нет смысла впихивать в серв средневековой РПГ тематики Индастриал Крафт или БилдКрафт.

Какие бывают сервера?

1. Первое, что надо выбрать — будет ли ваш серв ПвП, не-ПвП, или же ПвП можно будет каждому отключать-включать индивидуально.
(Отдельный нюанс — смогут ли игроки установить флаг не-ПвП на свой дом)

2. Многим нравятся песочницы. В стандартных версиях Майна уже много фишек, и серв может прожить и без модов. Такие сервера стабильны, живут долго без вайпов, и некоторым не охота разбираться в хитростях всяких модов.
Простая песочница всегда собирает 5-10 человек, которые хотят только строить.

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

4. Инженерный серв. Еще таких не было, но мы надеемся.. Смысл в том, что это продвинутая песочница. На ней стоят моды, которые добавляют красивые блоки для строительства. Треугольные, моды на мебель, полублоки РедПауэр и т.п. Чтобы можно было построить что-то необычное из необычных блоков. Однако, на таких сервах надо уменьшать халяву. Не рекомендовано ставить IС, BC, чтобы люди особо ценили свои блоки.

5. Техно-сервер. Самый стандартный в последнее время. Без комментов. Единственное — не стоит всё же его забивать всякой фигнёй. IC BC RP плюс парочка других модов вполне достаточно!
Вопросом является, стоит ли ставить на техно-серве ComputerCraft, и стоит ли разрешать в нем роботов. Роботы могут порушить экономику, но они клёвые. Да и сам КомпКрафт не все понимают как использовать.

6. РПГ-сервер. Самый сложный, но и самый крутой. Смысл в том, что на нём добавлены моды или плагины, которые добавляют характеристики вашего персонажа.
Эти плагины есть стандартные — Heroes, MCMMO, AncientRPG и т.д, но многие начинающие написатели плагинов пишут собственные, потому что это самое востребованное. Новые заклинания, новые навыки — сделать легко, сложно лишь настроить баланс.
Стандартные плагины тоже требуют долгой настройки и выдумывания классов.
Можно добавлять разные фишки для РПГ серверов. Например, Богов, или обязывать людей писать описание своего персонажа, или добавлять новых монстров, или плагин женитьбы Marriage, или много чего еще.
На сервах РПГ должна быть особая атмосфера сотрудничества — много кланов, городов, поэтому на них важна организация.
У нас никогда не получалось грамотно поставить и настроить плагин Factions. Честь тому, кто сможет это сделать. Потому что это не просто плагин создания кланов — он делает так, что чужие территории можно захватывать! А это очень круто — войны не просто ради убийств и шмоток, а ради собственного замка!
Отдельный вопрос — стоит ли ставить на таком серве EquivalentExchange. Хотя
этот мод «магический», но там слишком много багов, дюпа и грифа. Например, с помощью кольца Саурона можно рушить что угодно.

7. Военный сервер. ПвП сервер, на котором добавлены моды на оружие и (возможно) на танки или передвижения построек типа танков. Тут всё понятно. Главное — качественно устроить всё для хороших войнушек между игроками

8. Сервер выживания. Серв, на котором много монстров и трудно выжить. Честно говоря, монстры тупые, и трудно ими кого-то запугать. Большие количества ничего не решают. Однако, если сделать всё правильно, такой серв можно сделать интересным.

8. Экстрим (гриф) сервер. Серв, на котором нет или ограничены приваты. Тут можно грифать и разрушать постройки кого угодно, главное — найти и обойти ловушки. Кое-кому нравится, но многие просто не переносят такие сервы. Да и трудно там долго играть — надоедает, что всё, что построил и добыл, рано или поздно исчезает.

Это основные типы серверов. Однако, есть простор для фантазии. Выдумывайте новые идеи! Ищите охренительные моды на dev.bukkit.org, но следите за тем, чтобы они обновлялись под новую версию, и чтобы создатели не допускали багов.

Вот несколько идей, которые есть, но не реализованы еще:
1. Сервер Техно против Магии.
Смысл: мир поделён на две части огромным оврагом. В одной части живут Техники, имеющие доступ только к IC и BC, а в другой части — маги с доступом к EE и всякой магии. Между ними постоянно идёт война. Возможно, есть еще клан посредников, которые торгуют между сторонами, или подстрекают их к войне, или же воюют против всех.

2. Сервер летающих островов. Что-то вроде мира Ендера. Смысл в том, что место ограничено, и между островами трудно ходить, только по мостам, которые легко охранять.

3. Сервер Сталкера. Апокалиптическая атмосфера. Разрушенные небоскрёбы, ядерные электростанции, особая зона, плагин на радиацию, много ловушек, много монстров, в том числе нестандартных.

Следующий пункт — сервера, чья особенность — особая архитектура. Трудно сделать, потому что людей трудно заставить всё строить в одном стиле. Однако, это возможно.
Примеры таких идей:
1. Средневековые сервы. Постройки только в виде замков, деревень и другой средневековой хрени. Неплохо сочетается с РПГ тематикой.

2. Сервер Пони. Многие любят Пони. Целые сервы застроены их деревеньками и пиксель-артом.

3. Сервера в арабском стиле, сервера в космическом стиле, сервера Гномов (только подземное), и т.д. Придумать можно много вариантов!

Еще есть сервера с отдельным модом, меняющим всю игру.
На так
Примеры:
1. Hunger games (игры на выживание)
2. DotA в майнкрафте
3. DayZ мод для майна
4. Всевозможные арены и карты с собственными правилами

Отдельно тут стоят сервера ивентовые. Я рекомендую иметь возможность запускать целый сервер с отдельной картой, на которой будет проводиться ивент. Мы делали так уже несколько раз!
Это просто — зайти на planetminecraft.com, выбрать там хорошую карту Adventure, поставить ее на отдельный серв, и провести ивент! Можно, конечно, и самому построить карту в одиночной игре. Если вам это по зубам, делайте!

Разместите свой собственный сервер Rust — Rustafied

Файл пакетного сценария

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

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

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

  1.) эхо выкл.
2 :): начало
3 :) C: \ steamcmd \ steamcmd.exe + логин анонимный + каталог_установки_силы c: \ rustserver \ + app_update 258550 + выход
4 :) RustDedicated.exe -batchmode + server.port 28015 + server.level "Procedural Map" + server.seed 1234 + server.worldsize 4000 + server.maxplayers 10 + server.hostname "Имя сервера, как показано на клиентском сервере Список "+ server.description" Описание, отображаемое в окне подключения к серверу. " + server.url "http://yourwebsite.com" + сервер.headerimage "http://yourwebsite.com/serverimage.jpg" + server.identity "server1" + rcon.port 28016 + rcon.password letmein + rcon.web 1
5 :) перейти к началу
  

Примечание: Не используйте этот пример без внесения изменений. Номера строк показаны только для справки, и НЕОБХОДИМО удалить .

Вот объяснение каждой строки в пакетном файле.

echo off
Это подавляет желание окна консоли отображать каждую команду в пакетном файле по мере их выполнения.

: начало
Это метка начальной точки цикла.

C: \ steamcmd \ steamcmd.exe + анонимный вход + каталог_установки_ принудительного_установки c: \ rustserver \ + app_update 258550 + выход
Запускает SteamCMD для проверки обновлений сервера и применения при необходимости.

RustDedicated.exe -batchmode + server.port 28015 + server.level «Процедурная карта» + server.seed 1234 + server.worldsize 4000 + server.maxplayers 10 + server.hostname «Имя сервера, отображаемое на клиентском сервере. Список «+ сервер.description «Описание, отображаемое в окне подключения к серверу». + server.url «http://yourwebsite.com» + server.headerimage «http://yourwebsite.com/serverimage.jpg» + server.identity «server1» + rcon.port 28016 + rcon.password letmein + rcon. web 1

-batchmode
Открывает Unity в режиме без графического интерфейса и устраняет необходимость вмешательства человека.

+ server.port 28015
Порт подключения клиента Rust.

+ server.level «Процедурная карта»
Тип карты, который следует использовать.Возможны следующие варианты: «Процедурная карта», «Бесплодный», «Хаписский остров», «Савас-остров» и «Савас-остров_кот»

+ server.seed 1234
Определяет форму процедурных и пустых карт (используется с server.worldsize). Диапазон значений от 0 до 2147483647.

+ server.worldsize 4000
Определяет форму процедурных и пустых карт (используется с server.seed). Значения от 1000 до 6000.

+ server.maxplayers 10
Количество игроков, которые могут быть подключены

+ server.hostname «Имя сервера, отображаемое в списке клиентских серверов»
Имя сервера, отображаемое в списке серверов клиента

+ server.description «Описание, отображаемое в окне подключения к серверу».
Описание, отображаемое в окне подключения к серверу клиента

+ server.url «http://yourwebsite.com»
Действительный веб-сайт. Вызывает появление кнопки «Просмотр веб-страницы» в окне подключения.

+ server.headerimage «http: // yourwebsite.com / serverimage.jpg «
Допустимая ссылка для фонового изображения окна подключения. Используйте изображение JPG размером 512 x 256.

+ server.identity» server1 «
Имя каталога, используемое в качестве родительского для всего сервера Файлы. Не используйте пробелы или специальные символы.

+ rcon.port 28016
Порт подключения клиента Rcon.

+ rcon.password letmein
Пароль, необходимый для доступа Rcon. Не используйте пробелы или специальные символы.

+ rcon.web 1
Использует режим подключения через веб-сокет для rcon (рекомендуется)

goto start
Указывает пакетному файлу перейти к метке «start». Удалите эту строку, если вы не хотите, чтобы ваш сервер автоматически перезапускался после выключения.

.

Базовая структура

OAS 3 Эта страница относится к OpenAPI 3 — последней версии спецификации OpenAPI. Если вы используете OpenAPI 2 (fka Swagger), посетите страницы OpenAPI 2.

Базовая структура

Вы можете писать определения OpenAPI в YAML или JSON. В этом руководстве мы используем только примеры YAML, но JSON работает одинаково хорошо. Пример определения OpenAPI 3.0, написанный на YAML, выглядит так:

  openapi: 3.0.0
Информация:
  title: Образец API
  description: необязательное многострочное или однострочное описание в [CommonMark] (http: // commonmark.org / help /) или HTML.
  версия: 0.1.9

серверы:
  - url: http://api.example.com/v1
    description: Необязательное описание сервера, например Главный (производственный) сервер
  - url: http://staging-api.example.com
    description: Необязательное описание сервера, например Внутренний промежуточный сервер для тестирования

пути:
  / пользователи:
    получить:
      сводка: возвращает список пользователей.
      description: необязательное расширенное описание в CommonMark или HTML.
      ответы:
        '200': # код состояния
          описание: массив имен пользователей в формате JSON.
          содержание:
            приложение / json:
              схема:
                тип: массив
                Предметы:
                  тип: строка
  

Все имена ключевых слов чувствительны к регистру .

Метаданные

Каждое определение API должно включать версию спецификации OpenAPI, на которой это определение основано:

  openapi: 3.0.0  

Версия OpenAPI определяет общую структуру определения API — что вы можете документировать и как вы это документируете. OpenAPI 3.0 использует семантическое управление версиями с трехчастным номером версии. Доступны следующие версии: 3.0.0 , 3.0.1 , 3.0.2 и 3.0,3 ; они функционально одинаковы.

Раздел info содержит информацию API: заголовок , описание (необязательно), версия :

  информация:
  title: Образец API
  description: необязательное многострочное или однострочное описание в [CommonMark] (http://commonmark.org/help/) или HTML.
  версия: 0.1.9
  

title — ваше имя API. описание — это расширенная информация о вашем API.Он может быть многострочным и поддерживает диалект CommonMark Markdown для форматированного текстового представления. HTML поддерживается в той степени, в которой это предусмотрено CommonMark (см. Блоки HTML в спецификации CommonMark 0.27). версия — это произвольная строка, определяющая версию вашего API (не путайте ее с версией файла или версией openapi ). Вы можете использовать семантическое управление версиями, например major.minor.patch , или произвольную строку, например 1.0-beta или 2017-07-25 . info также поддерживает другие ключевые слова для контактной информации, лицензии, условий обслуживания и других деталей.

Ссылка: информационный объект.

Серверы

В разделе серверов указывается сервер API и базовый URL. Вы можете определить один или несколько серверов, например производственный и песочницу.

  серверов:
  - url: http://api.example.com/v1
    description: Необязательное описание сервера, например Главный (производственный) сервер
  - url: http: // staging-api.example.com
    description: Необязательное описание сервера, например Внутренний промежуточный сервер для тестирования
  

Все пути API указаны относительно URL-адреса сервера. В приведенном выше примере / users означает http://api.example.com/v1/users или http://staging-api.example.com/users , в зависимости от используемого сервера. Для получения дополнительной информации см. Сервер API и Базовый путь.

Пути

Раздел paths определяет отдельные конечные точки (пути) в вашем API и методы (операции) HTTP, поддерживаемые этими конечными точками.Например, GET / пользователи можно описать как:

  путей:
  / пользователи:
    получить:
      сводка: возвращает список пользователей.
      description: необязательное расширенное описание в CommonMark или HTML.
      ответы:
        '200':
          описание: массив имен пользователей в формате JSON.
          содержание:
            приложение / json:
              схема:
                тип: массив
                Предметы:
                  тип: строка
  

Определение операции включает параметры, тело запроса (если есть), возможные коды состояния ответа (например, 200 OK или 404 Not Found) и содержимое ответа.Для получения дополнительной информации см. Пути и операции.

Параметры

Операции могут иметь параметры, передаваемые через URL-адрес ( / users / {userId} ), строку запроса ( / users? Role = admin ), заголовки ( X-CustomHeader: Value ) или файлы cookie ( Cookie: debug = 0 ). Вы можете определить типы данных параметра, формат, являются ли они обязательными или необязательными, и другие детали:

  путей:
  / user / {userId}:
    получить:
      Сводка: возвращает пользователя по идентификатору.параметры:
        - имя: userId
          в: путь
          требуется: true
          description: Описание параметра в CommonMark или HTML.
          схема:
            тип: целое число
            формат: int64
            минимум: 1
      ответы:
        '200':
          описание: ОК
  

Для получения дополнительной информации см. Описание параметров.

Тело запроса

Если операция отправляет тело запроса, используйте ключевое слово requestBody для описания содержимого тела и типа мультимедиа.

  путей:
  / пользователи:
    после:
      резюме: создает пользователя.
      requestBody:
        требуется: true
        содержание:
          приложение / json:
            схема:
              тип: объект
              свойства:
                имя пользователя:
                  тип: строка
      ответы:
        '201':
          описание: Создано
  

Для получения дополнительной информации см. Описание тела запроса.

Ответы

Для каждой операции можно определить возможные коды состояния, например 200 OK или 404 Not Found, а также схему тела ответа . Схемы могут быть определены встроенными или ссылаться на них через $ ref . Вы также можете предоставить примеры ответов для разных типов контента:

  путей:
  / user / {userId}:
    получить:
      Сводка: возвращает пользователя по идентификатору.
      параметры:
        - имя: userId
          в: путь
          требуется: true
          описание: ID возвращаемого пользователя.схема:
            тип: целое число
            формат: int64
            минимум: 1
      ответы:
        '200':
          описание: объект пользователя.
          содержание:
            приложение / json:
              схема:
                тип: объект
                свойства:
                  Я бы:
                    тип: целое число
                    формат: int64
                    пример: 4
                  имя:
                    тип: строка
                    пример: Джессика Смит
        '400':
          описание: Указанный идентификатор пользователя недействителен (не число).'404':
          описание: Пользователь с указанным ID не найден.
        дефолт:
          описание: Неожиданная ошибка
  

Обратите внимание, что коды состояния ответа HTTP должны быть заключены в кавычки: «200» (OpenAPI 2.0 этого не требует). Для получения дополнительной информации см. Описание ответов.

Модели ввода и вывода

Глобальный раздел компонентов / схем позволяет вам определять общие структуры данных, используемые в вашем API.На них можно ссылаться через $ ref всякий раз, когда требуется схема - в параметрах, телах запросов и телах ответов. Например, этот объект JSON:

  {
  "id": 4,
  "name": "Артур Дент"
}
  

можно представить как:

  компонентов:
  схемы:
    Пользователь:
      свойства:
        Я бы:
          тип: целое число
        имя:
          тип: строка
      # Оба свойства обязательны
      обязательный:
        - Я бы
        - имя
  

, а затем указывается в схеме тела запроса и схеме тела ответа следующим образом:

  путей:
  / users / {userId}:
    получить:
      Сводка: возвращает пользователя по идентификатору.параметры:
        - в: путь
          имя: userId
          требуется: true
          тип: целое число
      ответы:
        '200':
          описание: ОК
          содержание:
            приложение / json:
              схема:
                $ ref: '# / components / schemas / User'
  / пользователи:
    после:
      сводка: создает нового пользователя.
      requestBody:
        требуется: true
        содержание:
          приложение / json:
            схема:
              $ ref: '# / components / schemas / User'
      ответы:
        '201':
          Описание: Создано  

Аутентификация

Ключевые слова securitySchemes и security используются для описания методов аутентификации, используемых в вашем API.

  компонентов:
  securitySchemes:
    BasicAuth:
      тип: http
      схема: базовая

безопасность:
  - BasicAuth: []  

Поддерживаемые методы аутентификации:

Для получения дополнительной информации см. Аутентификация.

Полная спецификация

Полная спецификация OpenAPI 3.0 доступна на GitHub: https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.3.md

Не нашли то, что искали? Задайте вопрос сообществу
Нашли ошибку? Сообщите нам

.

[ПРОЧИТАТЬ ОПИСАНИЕ] Новый тестовый сервер DBFT

[ПРОЧИТАТЬ ОПИСАНИЕ] Новый тестовый сервер DBFT - Roblox

Пожалуйста, включите Javascript, чтобы использовать все функции на этом сайте.

[ПРОЧИТАТЬ ОПИСАНИЕ] Новый тестовый сервер DBFT

 Приходите проверить мою новую игру на 100% лучше, чем эта
https://www.roblox.com/My/Groups.aspx?gid=3823107
-------------------------------------------------- -------------------------
-------------------------------------------------- -------------------------
-------------------------------------------------- -------------------------

Кредиты-
Карта - Дабиомару
Графические интерфейсы - 0Script0
Добро пожаловать в тестовую версию Dragon Ball Forgotten Tale!
{-Информация-}
Это тестовый сервер игры Dragon Ball Forgotten Tale, все, что вам нужно знать об игре, ниже.- SSJG «N»
- "V" SSJR
- SSJB "B"
- «К» Кайокен
{-Moves-}
- Меню "M" (прикрепите их)
- "E" Ki Blasts или Ki Wave Clash
- "Нажмите на игрока" Заблокировать
- Разблокировка "L"
- Блок "R" отключен / не работает
- Заряд "Z"
- Бой "L-Click R-Click"
- Т-образное столкновение луча на полной мощности
- Муха "Двойной космос"
- "Земля 

Играйте в эту игру с друзьями и другими приглашенными вами людьми.
Просмотрите все свои частные серверы на вкладке" Серверы ".

В настоящее время нет запущенных игр.

Запуск Roblox ...

Подключение к игрокам ...

Отметьте Запомните мой выбор и нажмите ОК в диалоговом окне выше, чтобы быстрее присоединяться к играм в будущем!

• 1

  Нажмите Сохранить файл при появлении окна загрузки

• 2

  Перейдите в раздел «Загрузки» и дважды щелкните RobloxPlayer.exe

• 3

  Нажмите Выполнить

• 4

  После установки нажмите Играть , чтобы присоединиться к действию!

• 5

  Щелкните Ok при появлении предупреждения

Программа установки Roblox должна загрузиться в ближайшее время.Если этого не произошло, начните загрузку сейчас. .