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

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в 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.: Как обычно, на все вопросы отвечаем в комментариях.

habr.com

Как создать свой первый безопасный веб-сервер, готовый к продуктиву

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

Для прогона тестов мы будем использовать Amazon EC2, но можно взять и Amazon LightSail, Digital Ocean, Vultr или другой сервис. Все они конфигурируются одинаково, так что выбирайте тот, который вам по душе.

Создаём публичный и приватный SSH-ключи

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

SSH-ключи мы будем создавать с помощью ssh-keygen.

$ ssh-keygen -t rsa -b 4096

В результате получим два файла: id_rsa и id_rsa.pub (приватный и публичный ключи). Никогда и никому не передавайте свой приватный ключ.

Подробную инструкцию по созданию ключей вы найдёте здесь.

Импорт публичного ключа в Amazon

Импортируем только что созданный публичный ключ в платформу Amazon.

1. Заходим в консоль управления Amazon.
2. Кликаем AWS services → Compute > EC2
3. Кликаем на левое меню Network & Security → Key Pairs
4. Кликаем «Import Key Pair» и загружаем публичный ключ (id_rsa.pub)

Создаём свою виртуальную машину

Установим в Amazon EC2 виртуальную машину под управлением Ubuntu. Настройка подробно описана здесь:

1. Заходим в консоль управления Amazon.
2. Кликаем AWS services → Compute → EC2
3. Выбираем запускаемый экземпляр.
4. Выбираем один из образов. В нашем случае это будет Ubuntu Server 16.04 LTS (HVM), с SSD-накопителем (но вы можете выбрать то, что вам больше подходит).
5. Выбираем виртуальную машину (в соответствии с вашими нуждами). Кликаем «Review» и «Launch».
6. Открываем новую вкладку и импортируем в Amazon созданный публичный ключ.
7. Здесь нас попросят «выбрать существующую пару ключей или создать новую» («Select an existing key pair or create a new key pair»). Жмём «выбрать существующую» («Choose an existing key pair»). Выбираем ранее загруженный ключ.
8. Кликаем «Launch Instances».
9. Кликаем на ссылку виртуальной машины, которую мы только что создали.

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

Подключаемся к новому серверу

Обращаемся к виртуальной машине по SSH.

Пишем в терминале:

$ ssh <USЕR>@<IP-ADDRЕSS> -p 22 -i <PATH-TO-PRIVАTЕ-KEY>

• <USЕR>: пользователь Linux-системы. В случае с Amazon используйте ubuntu, на других сервисах — root
• <IP-ADDRЕSS>: IP-адрес созданной нами виртуальной машины. Это поле «Public DNS (IPv4)» во вкладке «Description» нашего сервера.
• <PATH-TO-PRIVATЕ-KEY>: полный путь к сгенерированному ранее приватному ключу (например, /Users/flavio/.ssh/id_rsa).
• -i <PATH-TO-PRIVATЕ-KEY>: это можно пропустить, если вы добавили ключ в свой SSH-агент.

Даём доступ новому пользователю

Создадим новый аккаунт пользователя по имени “wizard”:

$ sudo adduser wizard

Дадим “wizard” разрешение выполнять sudo. Откроем файл:

$ sudo nano /etc/sudoers.d/wizard

И зададим содержимое:

wizard ALL=(ALL) NOPASSWD:ALL

Создадим директории:

$ mkdir /home/wizard/.ssh
# create authorized_keys file and copy your public key here
$ nano /home/wizard/.ssh/authorized_keys
$ chown wizard /home/wizard/.ssh
$ chown wizard /home/wizard/.ssh/authorized_keys

Скопируем публичный ключ (PATH-TO-PUBLIC-KEY) и вставим в удалённый экземпляр /home/wizard/.ssh/authorized_keys. Настроим разрешения:

$ chmod 700 /home/wizard/.ssh
$ chmod 600 /home/wizard/.ssh/authorized_keys

Обеспечиваем безопасность

Обновляем все установленные пакеты.

$ sudo apt-get update
$ sudo apt-get upgrade

Меняем SSH-порт с 22 на 2201. Для конфигурирования файрвола (ufw, Uncomplicated Firewall, незатейливый файрвол) открываем файл /etc/ssh/sshd_config:

$ sudo nano /etc/ssh/sshd_config

и меняем эти данные:

Port 2201
PermitRootLogin no
PasswordAuthentication no
# add this to avoid problem with multiple sshd processes
ClientAliveInterval 600
ClientAliveCountMax 3

Перезапускаем SSH-сервис:

$ sudo service ssh restart

Конфигурируем Uncomplicated Firewall (UFW) так, чтобы пропускались только входящие подключения SSH (порт 2201), HTTP (порт 80) и NTP (порт 123).

# close all incoming ports
$ sudo ufw default deny incoming
# open all outgoing ports
$ sudo ufw default allow outgoing
# open ssh port
$ sudo ufw allow 2201/tcp
# open http port
$ sudo ufw allow 80/tcp
# open ntp port : to sync the clock of your machine
$ sudo ufw allow 123/udp
# turn on firewall
$ sudo ufw enable

Конфигурируем серверные часы

Устанавливаем в качестве локального часового пояса UTC:

$ sudo dpkg-reconfigure tzdata

Выбираем опцию ‘None of the Above’ и снова UTC.

Отключаемся и добавляем наш ключ в SSH-агент

Для отключения вводим:

$ exit

а потом добавляем ключ.

Добавляем в Amazon разрешения по порту

Это необходимо сделать в Amazon. Зададим SSH-порт, который будем использовать также на Amazon.

1. Заходим в консоль управления Amazon.
2. Кликаем AWS services > Compute > EC2
3. Кликаем на левое меню Network & Security → Security Groups
4. Выбираем группу безопасности, относящуюся к нашей виртуальной машине.
5. Кликаем Action > Edit Inbound Rules
6. Кликаем «добавить правило» («Add Rule») и задаём: Type: Custom TCP, Port Range: 2201, Source: 0.0.0.0/0 и Description: SSH

Подключаемся с новыми данными

Теперь вы можете подключиться к серверу по новому порту как новый пользователь:

$ ssh wizard@<IP-ADDRESS> -p 2201 -i <PATH-TO-PRIVATE-KEY>

Теперь у вас есть сервер, готовый обслуживать ваше приложение.

habr.com

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

Содежание:

Сервер рабочей группы
Сервер контроллер домена
Прокси Сервер
Сервер электронной почты
Веб сервер
Терминальный сервер
Сервер баз данных
Файловый сервер
Серверы приложений
Брандмауэры
Серверы 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. Если же на компьютере планируется запуск игрового сервера (весьма популярная инициатива в небольших локальных сетях), потребуется машина помощнее.

www.compline-ufa.ru

Как устроен сервер?

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

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

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

Роль серверов в IT

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

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

Итак, сервер выполняет следующие функции:

• Хранение различной информации в больших объемах;

• Обработку информации колоссальных объемов;

• Обеспечение стабильной работы сетевых сервисов.

Что же собой представляет прокси-сервер?

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

Что такое ДНС-сервер?

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

Замена таких чисел на доменные имена необходима по следующим причинам:

• Числа крайне трудно запомнить, а домены значительно проще;

• В случае переноса веб-сайта на другой домен, его айпи-адрес будет другим, но само доменное имя остается прежним.

Таким образом, ДНС-сервер представляет собой программно-аппаратный механизм, который преобразует буквенное значение адресов веб-страниц к их цифровому айпи-адресу.

Что такое веб-сервер?

Веб-сервер представляет собой компьютер, который выдает HTTP ответ на запросы браузеров. Также он еще может выступать в роли хранилища всевозможных файлов и БД, принадлежащих к веб-ресурсам.

Что собой представляет почтовый сервер?

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

xn--80aaapxgwipfbfj.xn--p1ai

Домашний сервер для работы и не только. Организация рабочего места ленивого инженера

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

Вспоминая слова одного преподавателя вуза: «Кто такой инженер? Это же лентяй! Вот он лежит на диване, смотрит телевзор. И захотелось ему переключить канал — но вставать то лень! „Ай, ну его, каналы вставать переключать — пойду-ка разработаю пульт дистанционного управления…“. Всегда хотелось сделать что-то интересное и максимально это автоматизировать…

Итак, исходные данные:

0. Работа удаленным инженером-администратором. Поддержка парка серверов/сервисов по части software и hardware.
1. Место дислокации — загородный дом.
2. Гигабитный интернет с резервированием (Просто всегда был рад помочь местным сете-строителям с настройкой и сборкой серверов.)
3. Отностительно надежная инфраструктура — водо-, газо-, электроснабжение.
4. Желание тишины и спокойствия автоматизации для комфортной работы и быта.

Задачи:
1. Удобная организация рабочего места с возможностью оперативного мониторинга.
2. Необходимая функциональность в свете безопасности, быстродействия и широкого спектра задач.
3. Энергоэффективность.
4. Изоляция рабочей среды от потенциальных угроз.

Сначала все и вся было уделом одного обычного ПК средней конфигурации — здесь и работа, и развлечения и веб-сервер. Круглосуточная работа, особенно в жилой комнате ну никак не устраивала ни меня, ни домочадцев. Появилось желание сделать все „раз и надолго“. Были испробованы множество вариантов — несколько ПК для разных задач в разных местах, Remote Desktop к рабочему ноутбуку, во избежание всевозможных переустановок, проблем привязки к оборудованию или операционной системе. Но однажды попробовав поиграться с одной из систем виртуализации, понял — это то что решило бы сразу много проблем. Это случилось как раз во время, когда в ESXi было упразднено множество ограничений в бесплатной версии, да так что теперь гипервизор годился прямо в мини-продакшн, для дома это уже была пушка по воробьям Отлично, начнем-с.

Первые грабли не заставили себя ждать. При переносе штатным инструментом (VMware vCenter Converter Standalone Client) ОС Windows 7 из доживающего свое винчестера ноутбука конечно же был словлен блускрин. Решение — загрузочный диск с любым редактором реестра, активация необходимых драйверов путем правки нужных значений (вариант решения).

Как же было приятно потом „лечить“ и украшать медленную 5-летнюю систему! Был произведен перенос всего медиаконтента, „не очень нужных“ программ, система сжата с 500 до 50 гигабайт. Все было чудесно, но, конечно сразу же захотелось „побыстрее“. Здесь начались размышления по поводу, собственно, серверной части. Было решено построить систему с запасом, максимально использовав комплектующие, которые уже были. Основное требование — бесшумность и производительность.

Итак, корпус — был вот такой: INPC DL36 — прочный, просторный корпус, который отлично подходил под все требования — полноценный размер материнской платы, 3U высота для использования полноценных радиаторов и бесшумного блока питания.

Конфигурация оборудования:

• Материнская плата Tyan S7012. 2xLGA1366, 4 сетевых интерфейса, встроенный IPMI, цена на ebay на момент покупки — $130
• Процессор 1 х Intel Xeon L5630. 4×2.13GHz, TDP 40W. Второй пока лежит без дела, хотя, как показали измерения, практически не повлиял на снижение средней потребляемой мощности (-10Вт). Цена 1шт. на момент покупки — $50 (ebay)
• Контроллер LSI 9261-8i. Минимально необходимый для полноценного использования SSD. Замеры iops внутри виртуальных машин это подтверждают. Цена на момент покупки $150 (ebay).
• Дисковая подсистема Здесь немного понервничал и все же раскошелился. RAID1 на базе 2 x Intel SSD DC S3500 Series (240GB, 2.5in SATA 6Gb/s, 20nm, MLC) + OCZ Deneva 2 480 GB для второстепенных задач, тем не менее требующих быстрой дисковой системы. HDD оказались просто не нужны, к тому же они были бы самым шумным элементом системы! Замер IOPS оказался в „пределах погрешности“ относительно теста производительности RAID при непосредственном подключении, без какой-либо виртуализации.
• Блок питания Chieftec Smart GPS-500C. Он просто бесшумен. Никакого писка дросселей, никаких шумов, абсолютно.
• Оперативная память В текущей конфигурации это 3х8Gb — вполне достаточно для текущих задач и неплохой запас на будущее, чтобы лишний раз не выключать сервер.
• Охлаждение Штатные вентиляторы были выкручены, на продув корпуса установлены Noctua NF-S12A PWM. Основной проблемой конечно же стало охлаждение процессоров. Было решено использовать штатный радиатор Intel STS100C (Cu+Al) вместе с регулируемым вентилятором (штатный даже на минимальных для запуска оборотах был очень шумным). Экспериментальным путем был подобран San Ace 80, регулировка осуществляется с помощью популярного step-down модуля на базе LM2596S. Путем подстройки напряжения получилось добиться скорости 500-700 оборотов, это практически бесшумная работа. Такой режим не допускает перегрева даже жарким летом, все показания датчиков в пределах нормы.

В планах переход на полностью пассивное охлаждение CPU.

Вот как это выглядит на данном этапе:

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

Попутно был развеян миф о потребности регулярной перезагрузки Windows:

Итак, сервер собран, далее приступим к повышению надежности в доступных нам пределах. Мною было продумано множество вариантов бесперебойного электропитания дома в целом, и сервера, в частности. От выделенного ИБП с минимально необходимой мощностью для питания сервера и базовых сетевых устройств до полного резервирования всего дома трехфазным ИБП. В итоге проб и ошибок был выбран все же самый адекватный вариант — ИБП средней мощности с запасом для питания критических устройств в течение хотя-бы 12 часов. Таковыми являются газовый котел, собственно, сервер, коммутатор провайдера, роутер, внутренние коммутаторы, видеокамеры, автоматические ворота, дежурное 12В освещение, аварийные розетки в доме и подсобном помещении. Добавление следующего по важности устройства — чайника, насосной станции очень сильно повышает требования к ИБП, поэтому в случае надобности аварийное снабжение переводится на бензиновый генератор. В качестве источника бесперебойного питания применен APC Smart-UPS 1500, в крайнем случае — достаточный для пуска 0.75кВт насосной станции. Аккумуляторный блок собран из 2х120А*ч батарей.

Потребление резервируемых устройств в штатном режиме:

Организация сети. В который раз пришлось на своем опыте убедиться в законе — если по плану необходимо проложить два кабеля — надо закладывать четыре! Даже без систем умного дома. После разнообразных перестановок была применена следующая схема. Для моей реализации сети идеальным роутером оказался, конечно же, MikroTik. Абсолютно все необходимые функции за минимальную стоимость, с минимальным энергопотреблением. Простая настройка локальной сети, безопасности доступа извне, резервирования каналов связи, дополнительных сервисов — устройство класса „один раз разобрался, настроил и забыл“. Функция резервной маломощной точки доступа Wi-Fi, потому как качественная раздача не является основной задачей подобных устройств. В роли главной точки беспроводного доступа был заказан небезызвестный Ruckus — поставил и забыл, проблемы с Wi-Fi прекратились раз и навсегда.

Два аплинка от провайдеров проверяются на доступность по приоритету (distance) — в случае проблем с приоритетным провайдером автоматически происходит переключение на резерв. Решение простое, не самое надежное, но, как правило, достаточное при типичных проблемах сетей в частном секторе — обрывы кабелей/отсутствие электропитания.

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

1. Основная рабочая система на базе Windows 7, та самая, с трудом и заботой перенесенная со славно поработавшего ноутбука.
2. Отдельная система для ведения финансового учета и проведения переводов — так же, впрочем, перенесенная с нетбука.
3. ОС с софтом для видеонаблюдения. Хотя полностью независимые системы и имеют свои преимущества — но полугодовой опыт использования виртуальной машины для этих целей показал отличную надежность такого решения. Видеонаблюдение было построено на базе камер Hikvision и бесплатного софт-сервера от этого же производителя.
4. Сетевое хранилище для медиаконтента (FreeNAS) — в основном для удобного обмена файлами между устройствами внутри локальной сети и просмотра на фото/видео на телевизоре.
5. Unix сервер, Debian/Ubuntu, без GUI. Как же без простой, безотказной системы под рукой — собрать статистику и вывести показания датчиков на веб-сервер, перекодировать видео с помощью ffmpeg, протестировать скрипты, и т.д.
6. Бонусы — однажды в экстренной ситуации пришлось даже спасать крупный сайт, вытаскивая контент из проблемного рейда, на лету завернув его в виртуальную машину и переместив на временный сервер.

Для взаимодействия с виртуальной средой установлен ПК с 23» монитором, на котором есть относительно мощная видеокарта для видео/игр, подключение к машинам происходит по RDP либо SSH. Если уж совсем лениво — то с ноутбука, лежа на диване.

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

habr.com

Как работает веб сервер? — Хабр Q&A

Это все может быть реализавано от системы к системе по разному. Но на обычном компьютере, в большинстве случаев, это работает примерно так. ОС (точнее драйвер сетевой карты) получает аппаратное прерывание, когда приходят данные на карту. К слову сказать есть так называемый механизм «опложенных прерываний». Если не вдаваться в подробности, то прерывания будут приходить не на каждый кусок данных полученных картой, а только тогда, когда софт разрешит себя прерывать. То есть: получил прерывание, запретил прерывания, начал обрабатывать все что пришло и приходит, закончил, разрешил прерывания. В зависимости от системы или ее настроек, драйвер уже может что-то сделать с данными. Намеренно не употребляю слово «пакет», ибо это пока только данные, лежащие в буфере. Потом после всех проверок, они могут быть переданы сетевому стеку OS. Сетевой стэк, собственно как и драйвер, как правило является модулем ядра. На самом деле сетевой стек — это, сильно конфигурируемая и многослойная/многоуровневая и сложная подсистема ядра, и как правило представляет не один модуль, а множество. На каждом уровне, в зависимости от его настройки и/или типа данных (толко теперь уместно их называть фреймами/пакетами/дейтаграммами) может приниматься решение, что с ним делать дальше. Например: форварднуть куда-нибудь, или скипнуть, или ответить на них прямо в ядре, не передавая наверх в юзер-спайс, или все же передать. Вот если это свой пакет, то есть cвой/правильный ip, если открыт порт на прослушку, например WEB сервером (80/tcp), с помощью описанного выше механизма сокетов, тогда он будет передан в юзе-спейс web серверу на обработку. Серверы могут его тоже обрабатывать по разному. Аппачи например, по крайней мере ранние его версии, не парился особо, выделял каждому соединению по потоку загружал туда что-то, что обработает этот запрос, и уходил слушать дальше. Но сильно-нагруженные серверы, так работать не смогут, ибо потоки много «весят», поэтому есть еще куча, более продвинутых, способов обработки запросов сервером. К слову сказать, есть серверы которые прямо в ядре и живут. Зоопарк серверов, ровно как и сетевых стеков, большой и слишком сложный для одного поста. Будет время опишу полнее и грамотнее. Но «вкратце» должно быть понятно.

qna.habr.com

Что такое сервер? — Сервер Гид

Технические отличия

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

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

Во-вторых, кластеризация. Сей процесс описал выше. В случае обычных PC такое доступно лишь условно.

В третьих, оперативная память с поддержкой ECC (автоматическая коррекция ошибок). Обычная ОЗУ способна обнаруживать ошибки, но исправить их на ходу — нет. Память с ECC не только обнаруживает ошибки, но и исправляет, соответственно, критическая масса недочетов, из-за которых понадобится перезагрузить устройство, попросту не накопится.

В четвертых, в сервер можно установить большое количество профессиональных видеокарт. Но стоит быть справедливым, в компьютер можно до 4-х, в рабочую станцию тоже сколько влезет.

Пятое. Накопители U.2, это более быстрый интерфейс, чем M.2 и лучше работает со случайными обращениями к накопителю.

Шестое. Высокий уровень отказоустойчивости. Можно использовать накопители и блоки питания с «горячей заменой». Фактически, компонент можно заменить без обесточивания устройства.

Как видите, сервер имеет существенные отличия от устройств потребительского сегмента. Вполне вероятно, без определенных качеств обойтись попросту не получится. Например, разместить 35 накопителей в пределах одного устройства, использовать распределенные сетевые компоненты с пропускной способность свыше 10GbE и так далее.

servergid.ru