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

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

API игровых серверов предоставляет все необходимые инструменты для создания выделенных игровых серверов. Вы можете разместить сервера самостоятельно или предоставить сообществу возможность заниматься ими. Подобные сервера наилучшим образом подходят в случае с высококонкурентными играми, такими как Dota 2, или в случае с постоянными серверами, которые продолжают работать, даже когда все игроки покинули игру, как в Team Fortress 2.

Окно поиска серверов Steam

Окно поиска серверов является важной частью интерфейса Steam.

Игроки могут открыть окно поиска серверов в клиенте Steam или в оверлее

При работе с функциями ISteamMatchmakingServers вам доступны те же данные, что и в окне поиска серверов.

• ISteamMatchmaking::GetFavoriteGameCount
• ISteamMatchmaking::GetFavoriteGame
• ISteamMatchmaking::AddFavoriteGame
• ISteamMatchmaking::RemoveFavoriteGame

Передача игрового сервера

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

Steamworks — это набор инструментов и служб от Valve, позволяющих настроить и поддерживать игру в Steam.

• Документация
• Главная
• Подготовка к работе
• Облик в магазине
• Возможности
• Финансы
• Продажи и продвижение
• SDK Steamworks
• Лицензирование интернет-кафе
• SteamVR

• Материалы
• SteamVR
• Программа интернет-кафе Steam
• Обсуждения Steamworks
• Видеоруководства по Steamworks
• Связаться с поддержкой

• Новости и обновления
• Блог Steamworks
• Блог Steam
• Блог SteamVR
• Блог Steam Deck

Что представляет собой игровой сервер? Как он работает

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

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

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

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

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

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

Архитектура сервера онлайн-игры на примере Skyforge

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

Обзор

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

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

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

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

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

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

• Существует пул физических серверов, на которых будет запускаться игра. Этот набор серверов и наше серверное приложение, которое на них запущено, называется 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 не может содержать игроков больше, чем мы готовы принять. В очередь игроков могут начать ставить и в том случае, если из-за бага или еще по каким-либо причинам сервер вдруг стал работать медленнее определенного порога. Лучше сделать приемлемый сервис для ограниченного числа клиентов, чем упасть для всех.

Заключение

• Невытесняющая многозадачность в Java www.youtube.com/watch?v=YWLHELcvNbE
• Нагрузочное тестирование в Skyforge, или Боты – санитары сервера habrahabr.ru/company/mailru/blog/193452habrahabr.ru/company/mailru/blog/191378
• Базы данных в онлайн-играх. От Аллодов Онлайн до Skyforge habrahabr.ru/company/mailru/blog/182088
• Остальные статьи allodsteam.ru/#posts

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

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

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

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

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

Что такое сервер, как он работает и какие есть виды серверов — объясняем простыми словами

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

Иллюстрация: Polina Vari для Skillbox Media

Роман Панов

Редактор и иллюстратор. Перепробовал пару десятков профессий — от тестировщика до модели, но нашёл себя в удалёнке. Учится в Skillbox и делится в своих текстах новыми знаниями.

Можно встретить выражения «сервер упал» или «сервер лежит». Это означает, что сервер перестал обрабатывать запросы. Чтобы узнать о серверах больше, прочитайте этот материал Skillbox Media. В нём рассказываем:

• что такое сервер;
• чем он отличается от обычного компьютера;
• как выглядит сервер;
• для чего он нужен;
• как работает сервер;
• где располагаются серверы.

Что такое сервер

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

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

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

Чем сервер отличается от обычного компьютера

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

Серверы — это служебные компьютеры, которые созданы для поддержки большого числа пользователей. Их название происходит от английского to serve, что значит «обслуживать» или «служить». Они способны одновременно запускать множество процессов, сервисов и приложений. У таких машин есть свои особенности.

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

Отказоустойчивость. Сервер должен работать без остановок и сбоёв. Поэтому все системы в нём обычно дублируются. Например, у него может быть две сетевые карты и пара блоков питания. Если одна деталь выйдет из строя, запасная её заменит.

Серверная операционная система. Операционная система — это набор программ, которые управляют всем оборудованием компьютера и служат основой для установки остального ПО. Серверная ОС отличается от пользовательской. На обычных компьютерах будет стоять, например, Windows, а на сервере — Windows Server. Для работы серверной операционной системы потребуется минимум 32 ГБ оперативной памяти.

Серверное программное обеспечение. Оно тоже отличается от ПО, которое устанавливают на обычные компьютеры. Серверное ПО отвечает за обработку запросов клиентов.

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

Есть три основные формы корпусов и, соответственно, три вида серверов: tower-сервер, rack-сервер и blade-сервер.

Tower-сервер — отдельный вертикальный шкаф. Он похож на башню, поэтому так и называется. Детали в его корпусе расположены далеко друг от друга, поэтому не сильно греются во время работы — можно использовать лёгкое охлаждение.

Несколько tower-серверов можно объединить в сеть. Однако такие серверы независимы друг от друга, поэтому для управления каждым требуется отдельный монитор, клавиатура и мышь.

Rack-сервер — самая распространённая форма корпуса сервера. Его часто называют стоечным сервером. Это автономный компьютер, все детали которого — платы, жёсткий диск, источник питания, вентилятор — помещены в корпус.

Rack-серверы устанавливают в специальные вертикальные шкафы с полками, которые называются стойками. Эти стойки поделены на отсеки, или юниты. В одной стойке может быть от 18 до 47 юнитов.

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

Blade-сервер — небольшой корпус, в который устанавливают самые необходимые детали: системную плату с процессором, контроллер, оперативную память. Blade-серверы не работают по отдельности — из них собирают блейд-систему с общими внешними компонентами: жёсткими дисками, блоками питания, охлаждением.

Системы устанавливают в такие же стойки, как и rack-серверы. Обычно они занимают четыре, семь или десять юнитов в стойке. Blade-серверы позволяют сократить объём оборудования без потери производительности.

Для чего нужен сервер

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

Мы перечислим самые распространённые виды серверов и задачи, которые они выполняют.

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

Сервер печати. Он позволяет нескольким пользователям совместно использовать один принтер. Сервер печати как программное обеспечение есть, например, в Windows. А компьютеры, отвечающие только за печать, почти не используют, потому что современные принтеры подключаются к сети напрямую.

Файловый сервер. Это сервер общего доступа к файлам. На нём можно закрыть просмотр файлов для каких-то пользователей или, наоборот, открыть и разрешить редактировать.

Веб-сервер. На нём размещают веб-сайты или программы. Пользователи могут получить доступ к ним через интернет.

FTP-сервер (file transfer protocol). Сервер для обмена файлами через локальную сеть или интернет.

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

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

Сервер удалённого доступа. Такой сервер позволяет получить доступ к вашему рабочему компьютеру и сети из любого места через интернет.

Игровой сервер. Такие серверы нужны для работы многопользовательских онлайн-игр.

DNS-сервер. Он хранит адреса серверов и сайтов, которые на них размещены. По запросу браузера DNS-сервер автоматически «находит» нужный сайт.

Как работает сервер

Работа сервера состоит в том, чтобы принимать, хранить и передавать данные. Если ещё проще — получать от клиента запросы и отвечать на них. Разберёмся с этим на примере посещения сайта. Вот как выглядит процесс:

• Вы вводите в адресную строку браузера имя сайта. Например: skillbox.ru.
• Браузер отправляет запрос на DNS-сервер и получает IP-адрес веб-сервера, на котором хранится сайт. Например, сайту skillbox.ru соответствует IP-адрес 178.248.237.96
• Браузер отправляет запрос на этот сервер.
• Веб-сервер обрабатывает запрос — обращается к серверу базы данных, генерирует HTML-код и посылает его браузеру.
• Браузер преобразует код в страницу и показывает вам её.

Всё это происходит за доли секунды.

Где находятся серверы

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

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

Вот какие условия нужны серверам:

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

Специальные центры называют дата-центрами или центрами (хранения и) обработки данных — ЦОД или ЦХОД. Компании, которые владеют дата-центрами, сдают в аренду свои серверы и сами обеспечивают необходимые условия эксплуатации. Также они могут предлагать в аренду место под сервер клиента.

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

Главное о серверах

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

Серверы могут быть в разных корпусах: tower, rack и blade. Tower-серверы — отдельные машины, а rack- и blade-серверы размещают в стойках.

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

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

Другие материалы Skillbox Media, которые могут быть вам полезны

• Подборка: 6 бесплатных конструкторов сайтов для магазинов, визиток, лендингов
• SERP в «Яндексе» и Google: что это, из чего состоит и как формируется
• Что такое хостинг для сайта и как его выбрать
• Какие бывают SSL-сертификаты, зачем они сайтам и как их получить
• Разбор факторов ранжирования в «Яндексе» и Google: как они работают