Любое оборудование, в том числе и серверное, иногда начинает работать непредсказуемо. Абсолютно не важно - новое ли это оборудование, или же оно уже несколько лет работает с полной нагрузкой.
Случаев сбоя и некорректной работы возникает множество и диагностика проблемы зачастую превращается в увлекательную головоломку.
Ниже мы расскажем о некоторых интересных и нетривиальных случаях.
Обнаружение неполадок
Регистрация проблемы чаще всего происходит после обращения клиентов в службу технической поддержки посредством тикет-системы.В случае обращения клиента, который арендует у нас выделенные серверы фиксированной конфигурации, мы проводим диагностику, чтобы выяснить, что проблема не носит программный характер.
Проблемы программного характера клиенты обычно решают собственными силами, тем не менее, мы в любом случае стараемся предложить помощь наших системных администраторов.
Если становится ясно, что проблема аппаратная (например, сервер не видит часть оперативной памяти), то на этот случай у нас всегда есть в резерве аналогичная серверная платформа.
В случае выявления аппаратной проблемы мы переносим диски со сбойного сервера на резервный и, после небольшой перенастройки сетевого оборудования, выполняется запуск сервера в работу. Таким образом данные не теряются, а время простоя не превышает 20 минут с момента обращения.
Примеры неполадок и способы их устранения
Сбой в работе сети на сервере
Существует вероятность, что после переноса дисков со сбойного сервера на резервный перестанет работать сеть на сервере. Это обычно происходит в случае использования операционных систем семейства Linux, например Debian или Ubuntu.Дело в том, что при первоначальной установке операционной системы, MAC-адреса сетевых карт записываются в специальный файл, расположенный по адресу: /etc/udev/rules.d/70-persistent-net.rules.
При старте операционной системы этот файл сопоставляет имена интерфейсов MAC-адресам. При замене сервера на резервный, MAC-адреса сетевых интерфейсов уже не совпадают, что и приводит к неработоспособности сети на сервере.
Для решения проблемы необходимо удалить указанный файл и перезапустить сетевой сервис, либо перезагрузить сервер.
Операционная система, не найдя этого файла, автоматически сгенерирует аналогичный и сопоставит интерфейсы уже с новыми MAC-адресами сетевых карт.
Перенастройки IP-адресов после этого не требуется, сеть сразу начнет работать.
Плавающая проблема с зависаниями
Однажды к нам на диагностику поступил сервер с проблемой случайных зависаний в процессе работы. Проверили логи BIOS и IPMI - пусто, никаких ошибок. Поставили на стресс-тестирование, нагрузив все ядра процессора на 100%, с одновременным контролем температуры - завис намертво через 30 минут работы.При этом процессор работал штатно, значения температуры не превышали стандартных при нагрузке, все кулеры были исправны. Стало ясно, что дело не в перегреве.
Далее следовало исключить вероятные сбои модулей оперативной памяти, поэтому поставили сервер на тест памяти с помощью достаточно популярного Memtest86+. Минут через 20 сервер ожидаемо завис, выдав ошибки по одному из модулей оперативной памяти.
Заменив модуль на новый, мы поставили сервер на тест повторно, однако нас ждало фиаско - сервер вновь завис, выдав ошибки уже по другому модулю ОЗУ. Заменили и его. Еще один тест - еще раз завис, вновь выдав ошибки по оперативной памяти. Внимательный осмотр слотов ОЗУ не выявил никаких дефектов.
Оставался один возможный виновник проблемы - центральный процессор. Дело в том, что контроллер оперативной памяти расположен именно внутри процессора и именно он мог давать сбой.
Сняв процессор, обнаружили катастрофу - один пин сокета был сломан в верхней части, обломанный кончик пина буквально прикипел к контактной площадке процессора. В итоге, когда на сервере не было нагрузки, все работало адекватно, но при увеличении температуры процессора контакт нарушался, тем самым прекращая нормальную работу контроллера оперативной памяти, что и вызывало зависания.
Окончательно проблема решилась заменой материнской платы, поскольку восстановить сломавшийся пин сокета нам, увы, не под силу, и это уже задача для сервисного центра.
Мнимое зависание сервера при установке ОС
Достаточно забавные случаи возникают, когда производители оборудования начинают менять архитектуру аппаратной части, отказываясь от поддержки старых технологий в пользу новых.К нам обратился пользователь с жалобой на зависание сервера при попытке установки операционной системы Windows Server 2008 R2. После успешного запуска инсталлятора, сервер прекращал реагировать на мышь и клавиатуру в KVM-консоли. Для локализации проблемы подключили к серверу физическую мышь и клавиатуру - все то же самое, инсталлятор запускается и перестает реагировать на устройства ввода.
На тот момент этот сервер у нас был одним из первых на базе материнской платы X11SSL-f производства Supermicro. В настройках BIOS был один интересный пункт Windows 7 install, выставленный в Disable. Поскольку Windows 7, 2008 и 2008 R2 разворачиваются на одном и том же инсталляторе, выставили этот параметр в Enable и чудесным образом мышь и клавиатура наконец-то заработали. Но это было лишь только начало эпопеи с установкой операционной системы.
На моменте выбора диска для установки ни одного диска не отображалось, более того, выдавалась ошибка необходимости установки дополнительных драйверов. Операционная система устанавливалась с USB-флешки и быстрый поиск в интернете показал, что такой эффект возникает, если программа установки не может найти драйвера для контроллера USB 3.0.
Википедия сообщила, что проблема решается отключением в BIOS поддержки USB 3.0 (XHCI-контроллера). Когда мы открыли документацию к материнской плате, нас ожидал сюрприз - разработчики решили полностью отказаться от контроллера EHCI (Enhanced Host Controller Interface) в пользу XHCI (eXtensible Host Controller Interface). Иными словами, все порты USB на этой материнской плате являются портами USB 3.0. И если отключить контроллер XHCI, то мы этим самым отключим и устройства ввода, сделав невозможным работу с сервером и соответственно установку операционной системы.
Поскольку серверные платформы не были оборудованы приводами для чтения CD/DVD дисков, единственным решением проблемы стало интегрирование драйверов непосредственно в дистрибутив операционной системы. Только интегрировав драйвера контроллера USB 3.0 и пересобрав установочный образ, мы смогли установить Windows Server 2008 R2 на этот сервер, а этот случай вошел в нашу базу знаний, чтобы инженеры не тратили лишнее время на бесплодные попытки.
Еще забавнее бывают случаи, когда клиенты привозят нам оборудование на размещение, а оно ведет себя не так, как ожидается. Именно так и произошло с дисковой полкой линейки Dell PowerVault.
Устройство представляет собой систему хранения данных c двумя дисковыми контроллерами и сетевыми интерфейсами для работы по протоколу iSCSI. Помимо этих интерфейсов присутствует MGMT-порт для удаленного управления.
Среди наших услуг для размещенного оборудования как раз есть специальная услуга «Дополнительный порт 10 Мбит/с», которую заказывают в случае необходимости подключения средств удаленного управления сервером. Эти средства носят разные названия:
- «iLO» у Hewlett-Packard;
- «iDrac» у Dell;
- IPMI у Supermicro.
Для ограничения скорости порт просто настраивается как 10BASE-T и включается в работу, имея максимальную скорость в 10 Мбит/с. После того, как все было готово - мы подключили MGMT-порт дисковой полки, но клиент почти сразу сообщил, что у него ничего не работает.
Проверив состояние порта коммутатора, мы обнаружили неприятную надпись «Physical link is down». Такая надпись говорит, что имеется проблем с физическим соединением между коммутатором и подключенным в него клиентским оборудованием.
Плохо обжатый коннектор, сломанный разъем, перебитые жилы в кабеле - вот небольшой перечень проблем, которые приводят именно к отсутствию линка. Разумеется, наши инженеры сразу взяли тестер витой пары и проверили соединение. Все жилы идеально прозванивались, оба конца кабеля были обжаты идеально. К тому же, включив в этот кабель тестовый ноутбук, мы получили как и положено соединение со скоростью 10 Мбит/с. Стало ясно, что проблема на стороне оборудования клиента.
Поскольку мы всегда стараемся помочь нашим клиентам в решении проблем, решили разобраться, что именно вызывает отсутствие линка. Внимательно изучили разъем порта MGMT - все в порядке.
Нашли на сайте производителя оригинальную инструкцию по эксплуатации, чтобы уточнить - возможно ли со стороны программного обеспечения «погасить» данный порт. Однако такой возможности не предусматривалось - порт в любом случае поднимался автоматически. Несмотря на то, что подобное оборудование должно всегда поддерживать Auto-MDI(X) - иными словами правильно определять какой кабель включен: обычный или кроссовер, мы эксперимента ради обжали кроссовер и включили в тот же порт коммутатора. Пробовали принудительно выставлять параметр дуплекса на порту коммутатора. Эффект был нулевой - линка не было и идеи уже заканчивались.
Тут кто-то из инженеров высказал абсолютно противоречащее здравому смыслу предположение, что оборудование не поддерживает 10BASE-T и будет работать только на 100BASE-TX или даже на 1000BASE-X. Обычно любой порт, даже на самом дешевом устройстве совместим с 10BASE-T и вначале предположение инженера отмели как “фантастику”, но от безысходности решили попробовать переключить порт в 100BASE-TX.
Нашему удивлению не было предела, линк мгновенно поднялся. Чем именно обусловлено отсутствие поддержки 10BASE-T на порту MGMT остается загадкой. Такой случай - очень большая редкость, но имеет место быть.
Клиент был удивлен не меньше нашего и очень благодарил за решение проблемы. Соответственно ему так и оставили порт в 100BASE-TX, ограничив скорость на порту непосредственно с помощью встроенного механизма ограничения скорости.
Отказ турбин охлаждения
Как-то раз к нам приехал клиент, попросил снять сервер и вынести его в сервисную зону. Инженеры все сделали и оставили его наедине с оборудованием. Прошел час, второй, третий - клиент все время запускал/останавливал сервер и мы поинтересовались, в чем же заключается проблема.Оказывается, что у сервера производства Hewlett-Packard отказало две турбинки охлаждения из шести. Сервер при этом включается, выдает ошибку по охлаждению и сразу выключается. При этом на сервере располагается гипервизор с критичными сервисами. Для восстановления штатной работы сервисов требовалось выполнить срочную миграцию виртуальных машин на другую физическую ноду.
Решили клиенту помочь следующим образом. Обычно сервер понимает, что с вентилятором охлаждения все хорошо, просто считывая количество оборотов. При этом, разумеется, инженеры Hewlett-Packard сделали все, чтобы нельзя было заменить оригинальную турбинку аналогом - нестандартный коннектор, нестандартная распиновка.
Оригинал такой детали стоит около $100 и ее нельзя просто так пойти и купить - надо заказывать из-за рубежа. Благо в интернете обнаружили схему с оригинальной распиновкой и выяснили, что один из пинов как раз отвечает за считывание количества оборотов двигателя в секунду.
Дальнейшее было делом техники - взяли пару проводов для прототипирования (волей случая оказались под рукой - некоторые наши инженеры увлекаются Arduino) и просто соединили пины от соседних рабочих турбинок с коннекторами вышедших из строя. Сервер запустился и клиенту наконец-то удалось выполнить миграцию виртуальных машин и запустить сервисы в работу.
Разумеется, что все это было выполнено исключительно под ответственность клиента, тем не менее в итоге такой нестандартный ход позволил сократить простой до минимума.
А где же диски?
В некоторых случаях причина проблемы порой настолько нетривиальна, что на ее поиск уходит очень большое количество времени. Так и получилось, когда один из наших клиентов пожаловался на случайный отвал дисков и зависание сервера. Аппаратная платформа - Supermicro в корпусе 847 (форм-фактора 4U) с корзинами для подключения 36-ти дисков. В сервере было установлено три одинаковых RAID-контроллера Adaptec, к каждому подключено по 12 дисков. В момент возникновения проблемы, сервер переставал видеть случайное количество дисков и зависал. Сервер вывели из продакшн и приступили к диагностике.Первое, что удалось выяснить - диски отваливались только на одном контроллере. При этом «выпавшие диски» исчезали из списка в родной утилите управления Adaptec и заново там появлялись только при полном отключении питания сервера и последующем подключении. Первое, что пришло на ум - программное обеспечение контроллера. На всех трех контроллерах стояли немного разные прошивки, поэтому было решено на всех контроллерах установить одну версию прошивки. Выполнили, погоняли сервер в режимах максимальной нагрузки - все работает как положено. Пометив проблему как решенную, сервер отдали клиенту обратно в продакшн.
Через две недели снова обращение с той же проблемой. Было решено заменить контроллер на аналогичный. Выполнили, прошили, подключили, поставили на тесты. Проблема осталась - через пару дней выпали все диски уже на новом контроллере и сервер благополучно завис.
Переустановили контроллер в другой слот, заменили бэкплейн и SATA-кабели от контроллера до бэкплейна. Неделя тестов и снова диски выпали - сервер вновь завис. Обращение в поддержку Adaptec результатов не принесло - они проверили все три контроллера и проблем не обнаружили. Заменили материнскую плату, пересобрав платформу чуть ли не с нуля. Все, что вызывало малейшие сомнения заменили на новое. И проблема вновь проявилась. Мистика да и только.
Проблему удалось решить случайно, когда стали проверять в отдельности каждый диск. При определенной нагрузке один из дисков начинал стучать головами и давал короткое замыкание на порт SATA, при этом какая-либо аварийная индикация отсутствовала. Контроллер при этом переставал видеть часть дисков и вновь начинал их опознавать только при переподключении по питанию. Вот так один единственный сбойный диск выводил из строя всю серверную платформу.
Заключение
Конечно, это лишь малая часть интересных ситуаций, которые были решены нашими инженерами. Некоторые проблемы «отловить» достаточно непросто, особенно когда в логах нет никаких намеков на произошедший сбой. Зато любые подобные ситуации стимулируют инженеров детально разбираться в устройстве серверного оборудования и находить самые разнообразные решения проблем.Вот такие забавные случаи были в нашей практике.
А с какими сталкивались вы? Добро пожаловать в комментарии.
Для чего нужен сервер и когда стоит покупать его для своего бизнеса?
Для начала уточним, что сервер – это оборудование, которое использует серверное программное обеспечение . Он оптимизирован для работы с другими компьютерами (клиентами). Клиентами сервера могут быть компьютеры, телефоны, факсы, принтеры и все другие устройства, которые подключаются к интернету. Чем больше информации Вы планируете хранить на серверном оборудовании, тем мощнее должен быть сервер. Для каких целей арендуют сервер? Подробнее в материале на блоге ГиперХост .
Компании используют сервера для общего доступа всех сотрудников к определенной информации и для общего пользования доступными ресурсами. Для того, чтобы сервер хорошо работал, нанимают системного администратора. Он настраивает оборудования для работы, делает резервное копирования, устраняет возникшие неполадки. Корректная работа сервера напрямую зависит от качественной и профессиональной работы сис.админа . Обратите внимание, что для всех пользователей услуг компании предоставляется бесплатная техническая поддержка, вне зависимости от тарифа.
Но все же многие считают, что иметь собственный сервер не обязательно, можно воспользоваться обычным компьютером. Но хотим вас предупредить, что это очень недальновидное решение. Компьютер не сможет выполнять множество задач, которые выполняет сервер. Прежде всего, сервер это не только хранение информации, но и выполнение большого количества одновременных запросов, с которыми обычный ПК не справится и в критический момент просто потеряет всю необходимую информацию.
Если Ваш бизнес работает на перспективное будущее, следует задуматься о выборе сервера.
Для начала разберемся, какие есть виды серверов в зависимости от выполняемых функций.
Почтовый сервер принимает непосредственное участие в принятии и отправлении электронной почты. Вы отправляете письмо на электронный адрес, но оно сначала попадает на почтовый сервер, где происходит его обработка. Индексируется адрес получателя и письмо отправляется. В этом процессе участвует несколько почтовых серверов, которые обмениваются необходимой информацией. О популярных почтовых серверах Exim, Postfix, Sendmail можно прочитать в статье.
Файловый сервер хранит все файлы сети, к которым происходит доступ с других компьютеров. Для обмена файлами используется протокол FTP, с помощью которого пользователь может загружать все файлы в сети (картинки, видео, аудио). Файловым сервером можно считать любой компьютер, который имеет много дискового пространства для хранения информации.
Веб-сервер – сервер подключенный к Интернету и принимающий запросы пользователей по протоколу HTTP. Все сайты, который есть в сети, расположены на веб-серверах. Такой вид сервера – непосредственный проводник между сайтом и клиентами. Веб-сервер получает запрос, далее обрабатывает его и выдает результат (файловый или гипертекстовый). По своей сути веб-хостинг и веб-сервер понятия идентичны. Веб сервер Nginx и apache – что это и как работает данная связка? Ответ на данный вопрос .
Сервера баз данных. В большинстве все программы используют базы данных. Данный вид серверов обеспечивают доступ к данным с помощью системы клиент-сервер. Самыми популярными серверами баз данных являются SQL SERVER (Microsoft), SQL BASE SERVER, Oracle SERVER (Oracle Corporation), IBM DB2, Informix. Они работают на платформе различных ОС, таких как MSDOS, OS/2, Xenix, Unix.
Прокси-сервер – можно сказать, что это тот же веб-сервер, но он осуществляет запросы в сети вместо посетителя. Это по сути комплекс программ. Вы подключаетесь к прокси-серверу, даете ему запрос, а он ищет информацию вместо Вас, в некоторых случаях изменяя ее. Работа с прокси-сервером позволяет защитить компьютер клиента от вредоносных программ, быть анонимным в сети, ограничить доступ к определенным ресурсам или наоборот обойти запреты. Простая установка прокси сервера на свой VPS за 1 минуту, подробнее .
Игровой сервер обеспечивает связь между клиентами в сети. Клиенты взаимодействуют в игре и общаются между собой. Данный сервер получает информацию, обрабатывает запросы, обновляет систему и рассылает результаты всем участникам игры. В основном, игровые сервера размещают у себя хостинг-компании.
В наше время очень трудно представить работу предприятия без использования серверов. В этом трудоемком процессе участвуют сервера всех типов.
Причины, по которым можно определить, нужно ли для вашей фирмы?
- Вы желаете систематизировать и централизовать всю информацию, которая находится в вашей компании.
- Многим сотрудникам необходимо подключаться к сети, независимо от места их нахождения.
- Вам необходимо много места для хранения информации.
- Вы планируете запустить программное обеспечение, которое поможет развитию вашего бизнеса.
- Ваша компания развивается и растет, количество сотрудников постоянно увеличивается.
- Ваш бизнес не очень большой, но Вы хотите выглядеть как настоящий профессионал.
От правильности выбора сервера зависит успешная работа компании, ведь сервера помогают организовать бесперебойное функционирование предприятия, и связывают отдельные подразделения, например, те, которые находятся в разных городах.
Специалисты компании HyperHost с удовольствием подберут наиболее оптимальный физический или , по всем параметрам, сервер и обеспечат стабильность Ваших проектов. Сравнение также поможет сделать вам верный выбор и правильно подобрать услугу в зависимости от поставленной цели.
Необходимо выбрать операционную систему для работы сервера? Данная поможет вам сделать правильный выбор и оценить все возможности каждой ОС. О панелях управления для серверов с Linux .
42788 раз(а) 18 Сегодня просмотрено раз(а)
В этой статье я постараюсь максимально широко изложить схемы работы веб-серверов. Это поможет выбрать сервер или решать, какая архитектура быстрее, не основываясь на часто необъективных бенчмарках.
В общем - статья представляет собой глобальный обзор "что бывает". Без циферок.
Статья написана на основе опыта работы с серверами:
- Apache, Lighttpd, Nginx (на C)
- Tomcat, Jetty (на Java)
- Twisted (Python)
- Erlang OTP (язык Erlang)
- и операционными системами Linux, FreeBSD
Тем не менее, принципы достаточно общие, поэтому должны распространяться в каком-то виде на OS Windows, Solaris, и на большое количество других веб-серверов.
Цель веб-сервера
Цель веб-сервера проста - обслуживать одновременно большое количество клиентов, максимально эффективно используя hardware. Как это сделать - в этом основная заморочка и предмет статьи;)
Работа с соединениями
С чего начинается обработка запроса? Очевидно - с приема соединения от пользователя.
Для этого в разных OS используются разные системные вызовы. Наиболее известный и медленный на большом количестве соединений - select . Более эффективные - poll, kpoll, epoll.
Современные веб-серверы постепенно отказываются от select.
Оптимизации ОС
Еще до приема соединения возможны оптимизации на уровне ядра ОС. Например, ядро ОС, получив соединение, может не беспокоить веб-сервер, пока не произошло одно из событий.
- пока не пришли данные (dataready)
- пока не пришел целиком HTTP-запрос (httpready)
На момент написания статьи оба способа поддерживаются во FreeBSD (ACCEPT_FILTER_HTTP, ACCEPT_FITER_DATA), и только первый - в Linux (TCP_DEFER_ACCEPT).
Эти оптимизации позволяют серверу меньше времени простаивать в ожидании данных, повышая таким образом общую эффективность работы.
Соединение принято
Итак, соединение принято. Теперь на плечи сервера ложится основная задача - обработать запрос и отослать ответ посетителю. Будем здесь рассматривать только динамические запросы, существенно более сложные, чем отдача картинок.
Во всех серверах используется асинхронный подход.
Он заключается в том, что обработка запроса спихивается куда-нибудь "налево" - отдается на выполнение вспомогательному процессу/потоку, а сервер продолжает работать и принимать-отдавать на выполнение все новые соединения.
В зависимости от реализации - процесс-помощник ("worker") может пересылать результат обратно серверу целиком (для последующей отдачи клиенту), может передавать серверу только дескриптор результата (без копирования), или может отдавать результат клиенту сам.
Основные стратегии работы с worker"ами
Работа с воркерами состоит из нескольких элементов, которые можно по-разному комбинировать и получать разный результат.
Тип worker"а
Основных типов два - это процесс и поток. Для улучшения производительности иногда используют оба типа одновременно, порождая несколько процессов и кучу потоков в каждом.
Процесс
Различные worker"ы могут быть процессами. В этом случае они не взаимодействуют между собой, и данные различных worker"а полностью независимы друг от друга.
Поток
Потоки, в отличие от процессов, имеют общие, разделяемые структуры данных. В коде worker"а должна быть реализована синхронизация доступа, чтобы одновременная запись одной и той же структуры не привела к хаосу.
Адресное пространство
Каждый процесс, в том числе и сервер, обладает своим адресным пространством, которое использует для разделения данных.
Внутри сервера
При работе внутри сервера - worker имеет доступ к данным сервера. Он может поменять любые структуры и делать разные гадости, особенно если написан с ошибками.
Плюсом является отсутствие пересылки данных из одного адресного пространства в другое.
Снаружи сервера
Worker может быть запущен вообще независимо от сервера и принимать данные на обработку по специальному протоколу (например FastCGI).
Конечно, этот вариант - самый безопасный для сервера. Но требует дополнительной работы по пересылке запроса - результата между сервером и worker"ом.
Рождение worker"ов
Чтобы обрабатывать много соединений одновременно - нужно иметь достаточное количество рабочих.
Основных стратегий - две.
Статика
Количество рабочих может быть жестко фиксированно. Например, 20 рабочих процессов всего. Если же все рабочие заняты и приходит 21й запрос - сервер выдает код Temporary Unavailable - "временно недоступен".
Динамика
Для более гибкого управления ресурсами - рабочие могут порождаться динамически, в зависимости от загрузки. Алгоритм порождения рабочих может быть параметризован, например (Apache pre-fork), так:
- Минимальное количество свободных рабочих = 5
- Максимальное количество свободных рабочих = 20
- Всего рабочих не более = 30
- Начальное количество рабочих = 10
Чистка между запросами
Рабочие могут либо заново инициализовать себя между запросами, либо - просто обрабатывать запросы один за другим.
Чистый
Перед каждым запросом очищается от того, что было раньше, чистит внутренние переменные и пр.
В результате нет проблем и ошибок, связанных с использованием переменных, оставшихся от старого запроса.
Персистентный
Никакой очистки состояния. В результате - экономия ресурсов.
Разбор типичных конфигураций
Посмотрим, как эти комбинации работают на примере различных серверов.Apache (pre-fork MPM) + mod_php
Для обработки динамических запросов используется модуль php, работающий в контексте сервера.- Процесс
- Внутри сервера
- Динамика
- Чистый
Apache (worker MPM) + mod_php
Для обработки динамических запросов используется модуль php, работающий в контексте сервера.
При этом, так как php работает в адресном пространстве сервера, разделяемые потоками данные периодически портятся, поэтому связка нестабильна и не рекомендована. Это происходит из-за ошибок в mod_php, который включает в себя ядро PHP и различные php-модули.
Ошибка в модуле, благодаря одному адресному пространству, может повалить весь сервер.
- Поток
- Внутри сервера
- Динамика
- Чистый
Apache (event mpm) + mod_php
Event MPM - это стратегия работы с worker"ами, которую использует только Apache. Все - точно так же, как с обычными потоками, но с небольшим дополнением для обработки Keep-Alive
Установка Keep-Alive служит для того, чтобы клиент мог прислать много запросов в одном соединении. Например, получить веб-страницу и 20 картинок. Обычно, worker заканчивает обработку запроса - и ждет какое-то время (keep-alive time), не последуют ли в этом соединении дополнительные запросы. То есть, просто висит в памяти.
Event MPM создает дополнительный поток, который берет на себя ожидание всех Keep-Alive запросов, освобождая рабочего для других полезных дел. В результате, общее количество worker"ов значительно сокращается, т.к никто теперь не ждет клиентов, а все работают.
- Поток
- Внутри сервера
- Динамика
- Чистый
Apache + mod_perl
Особенность связки Apache с mod_perl - в возможности вызывать Perl-процедуры по ходу обработки запроса апачем.
Благодаря тому, что mod_perl работает в одном адресном пространстве с сервером - он может регистрировать свои процедуры через Apache hooks, на разных стадиях работы сервера.
Например, можно работать на той же стадии, что и mod_rewrite, переписывая урл в хуке PerlTransHandler.
Следующий пример описывает rewrite с /example на /passed, но на перле.
# в конфиге апача при включенном mod_perl PerlModule MyPackage::Example PerlTransHandler MyPackage::Example # в файле MyPackage/Example.pm package MyPackage::Example use Apache::Constants qw(DECLINED); use strict; sub handler { my $r = shift; $r->uri("/passed") if $r->uri == "/example" return DECLINED; } 1;
К сожалению, mod_perl - весьма тяжелый сам по себе, поэтому использование его лишь реврайтов - весьма накладно.
В отличие от mod_php, перловый модуль персистентен, т.е не инициализует себя заново каждый раз. Это удобно, т.к освобождает от необходимости загружать заново большую пачку модулей перед каждым запросом.
- Процесс/поток - зависит от MPM
- Внутри сервера
- Динамика
- Персистентный
Twisted
Этот асинхронный сервер написан на Python. Его особенность - в том, что программист веб-приложения сам создает дополнительных рабочих и дает им задания. # пример кода на сервере twisted # долгая функция, обработка запроса def do_something_big(data): .... # в процессе обработки запроса d = deferToThread (do_something_big, "параметры") # привязать каллбеки на результат do_something_big d.addCallback(handleOK) # .. и на ошибку при выполнении do_something_big d.addErrback(handleError)Здесь программист, получив запрос, использует вызов deferToThread для создания отдельного потока, которому поручено выполнить функцию do_something_big. При успешном окончании do_something_big, будет выполнена функция handleOK, при ошибке - handleError.
А текущий поток в это время продолжит обычную обработку соединений.
Все происходит в едином адресном пространстве, поэтому все рабочие могут разделять, например, один и тот же массив с пользователями. Поэтому на Twisted легко писать многопользовательские приложения типа чата.
- Поток
- Внутри сервера
- Динамика
- Персистентный
Tomcat, Servlets
Сервлеты - классический пример поточных веб-приложений. Единый Java-код приложения запускается во множестве потоков. Синхронизация обязательна и должна выполняться программистом.
- Поток
- Внутри сервера
- Динамика
- Персистентный
FastCGI
FastCGI - интерфейс общения web-сервера с внешними worker"ами, которые обычно запущены как процессы. Сервер в специальном (не HTTP) формате передает переменные окружения, заголовки и тело запроса, а worker - возвращает ответ.
Есть два способа порождения таких worker"ов.
- Интегрированный с сервером
- Отдельный от сервера
В первом случае сервер сам создает внешние рабочие процессы и управляет их числом.
Во втором случае - для порождения рабочих процессов используется отдельный "spawner", второй, дополнительный сервер, который умеет общаться только по FastCGI-протоколу и управлять рабочими. Обычно spawner порождает рабочих в виде процессов, а не потоков. Динамика/Статика - определяется настройками spawner"а, а Чистый/Персистентный - характеристиками рабочего процесса.
Пути работы с FastCGI
С FastCGI можно работать двумя путями. Первый способ - самый простой, его использует Apache.
получить запрос -> отдать на обработку в FastCGI -> подождать ответа -> отдать ответ клиенту.
Второй способ используют сервера типа lighttpd/nginx/litespeed/и т.п.
получить запрос -> отдать на обработку в FastCGI -> обработать других клиентов -> отдать ответ клиенту, когда придет.
Отмеченное отличие позволяет Lighttpd + fastcgi работать эффективнее, чем это делает Apache, т.к пока процесс Apache ждет - Lighttpd успевает обслужить другие соединения.
Режимы работы FastCGI
У FastCGI есть два режима работы.- Responder - обычный режим, когда FastCGI принимает запрос и переменные, и возвращает ответ
- Authorizer - режим, когда FastCGI в качестве ответа разрешает или запрещает доступ. Удобно для контроля за закрытыми статическими файлами
Оба режима поддерживаются не во всех серверах. Например, в сервере Lighttpd - поддерживаются оба.
FastCGI PHP vs PERL
PHP-интерпретатор каждый раз очищает себя перед обработкой скрипта, а Perl - просто обрабатывает запросы один за другим в цикле вида:
Подключить модули; while (пришел запрос) { обработать его; print answer; } Поэтому Perl-FastCGI гораздо эффективнее там, где большУю часть времени выполнения занимают include вспомогательных модулей.
Резюме
В статье рассмотрена общая структура обработки запросов и виды worker"ов. Кроме того, заглянули в Apache Event MPM и способы работы с FastCGI, посмотрели сервлеты и Twisted.
Надеюсь, этот обзор послужит отправной точкой для выбора серверной архитектуры Вашего веб-приложения.
Внимание! Данная программа не является обязательной. Если Вы решили ее использовать, то рекомендуем поручить установку и настройку данной программы специалисту, например, администратору сети.
Скачать программу можно с сайта по следующему адресу:
Общее описание
Сервер предназначен для обслуживания баз данных в формате DВase и Paradox с использованием драйверов BDE фирмы Inprise (Borland). Кроме того, он может выступать в роли Web-сервера.
При модификации базы (добавление, удаление, изменение) используется технология «клиент-сервер». Доступ к базе данных на чтение обеспечивается стандартными средствами BDE по технологии «файл-сервер». При этом клиентские программы открывают файлы базы данных только на чтение, а любое изменение данных осуществляет сервер.
Использование сервера позволяет избежать проблем, связанных с одновременным изменением базы несколькими пользователями через сеть. Сервер модифицирует базу в монопольном режиме. Благодаря этому обеспечивается надежное хранение и безопасная модификация данных.
Встроенный в программу Web-сервер позволяет организовать публикацию вашей информации в Intranet/Internet сети, а также обеспечивает удаленный контроль работы сервера.
Сервер может работать на компьютерах с установленной операционной системой Windows 95/98/2000/XP/Vista, Windows NT и настроенным протоколом TCP/IP . При работе под Windows NT, возможна установка сервера как сервиса.
Сервер может одновременно обслуживать несколько баз данных.
Контроль работы сервера может осуществляться дистанционно с помощью любого Web-браузера, например, Netscape Navigator, Microsoft Internet Explorer и т.п.
Установка сервера
Программа сервера может работать на любом компьютере в сети. Предварительно на этом компьютере необходимо установить и настроить BDE . Настройка BDE для сервера аналогична настройке BDE для работы Инфо-Бухгалтера (см. раздел Ошибка: источник перёкрестной ссылки не найден «Ошибка: источник перёкрестной ссылки не найден»).
Если база данных располагается на этой же машине, что и программа-сервер, то необходимо использовать команду SUBST (для Windows 95/98/2000/XP/7), так как название сетевого диска и путь к базе должны быть одинаковы для всех машин, в том числе и для машины с сервером.
Установите сервер на выбранную машину.
Вставьте дистрибутивный диск в привод CD-ROM и запустите файл InfoSrv203_setup. exe , располагающийся в директории \Setup\Infosvr\Server2 . Далее следуйте инструкциям программы установки.
После установки в каталоге с сервером будут содержаться следующие файлы и подкаталоги:
ibserv32.exe – сервер программы Инфо-Бухгалтер;
ibserv32.ini – файл настроек сервера;
WWW – подкаталог Web-сервера.В каталоге WWW по умолчанию содержатся файлы:
index.html – HTML-скрипт для отображения статистики работы сервера. В этом каталоге Вы можете размещать свои файлы, которые будут доступны по HTTP протоколу.
stat.html – пример файла шаблона статистики работы Инфо-Бухгалтера.
В процессе работы сервера создаются файлы:
ibserv.log – информация о работе сервера.
ibserv.jrn – журнал работы сервера.
Журнал создается только в том случае, если в файле ibserv32.ini параметр sqlTrace =1.
Установка сервера в качестве сервиса Windows NT
Для регистрации сервера необходимо запустить программу ibserv32 с ключом /i ., т.е. ibserv32. exe /i .
После этого средствами Windows NT (значок «Службы» в «Панели управления») установить необходимый режим работы сервиса (автомат или вручную). Имя сервиса – «InfoBuhDBServer».
Внимание! Необходимым условием правильной работы программы является эквивалентность путей к базе данных, а также путей к файлу P doxusrs.net , на сервере и рабочей станции (использование команды SUBST невозможно). Одному из локальных дисков сервера необходимо присвоить букву, совпадающую с названием сетевых дисков на рабочих станциях. Для правильного определения локальных и сетевых путей необходимо открыть корень этого диска на полный доступ, а с рабочих станций подключить корень этого диска в качестве сетевого диска.
Обязательно необходимо определить учетную запись, под которой будет запускаться сервер. В данной учетной записи должен быть указан пользователь с необходимыми полномочиями, например, Администратор.
Для удаления сервиса остановите его средствами Windows NT (Пункт «Службы» в «Панели управления»), а затем запустите ibserv32 с ключом /u .
Настройка сервера
Настройка сервера осуществляется посредством файла ibserv32.ini .
Рассмотрим назначение секций этого файла:
Запуск сервера
Запуск сервера осуществляется запуском файла ibserv32.exe . Если сервер установлен, как сервис для Windows NT, то запуск осуществляется автоматически или вручную с помощью значка «Службы» в «Панели управления».
Контроль работы сервера
Контроль работы сервера осуществляется с помощью консоли сервера:
Рис 19. Сервер программы «Инфо-Бухгалтер».
Внимание! При установке сервера в качестве сервиса Windows NT консоль недоступна.
Контроль работы сервера может также осуществляться удаленно при помощи Web-браузера (Netscape Navigator или Microsoft Internet Explorer).
Дополнение к HTML для контроля сервера
Для контроля работы сервера применяется динамический HTML, создаваемый по шаблону. В этом шаблоне Вы можете использовать следующие обозначения переменных:
##SERVREGIM# – режим работы сервера
##SERVOSVERSION# – версия ОС сервера
##SERVVERSION# – версия сервера
##SERVTIME# – текущее время на сервере
##LONGTIME# – время работы сервера
##IBZAPROS# – количество выполненных запросов
##IBBASE# – количество открытых баз
##IBERROR# – возникло ошибок
В каталоге WWW директории, где установлена программа, находится файл stat.html , содержащий пример файла шаблона статистики работы Инфо-Бухгалтера.
Рис 20. Файл статистики stat.html .
Настройка программы для работы с сервером
На компьютере с установленным Инфо-Бухгалтер в каталоге Windows (или другом каталоге, в который установлен Windows) находится файл ibw.ini . В этот файл в секцию необходимо внести следующие изменения:
После изменения параметров в этом файле, необходимо перезагрузить программу и, если изменился параметр UseServer , то удалить файлы Eventnet.db и Eventnet.px во всех используемых базах данных.
Внимание!
- Нельзя одновременно работать с одной базой данных пользователям, использующим и не использующим сервер;
- При переходе к использованию сервера и обратно (параметр UseServer ) необходимо уничтожать файлы Eventnet.db и Eventnet.px во всех используемых Вами базах. Невыполнение этого требования может привести к непредсказуемым последствиям;
- При использовании сервера невозможна проверка базы данных.
- 283 просмотра
Ниже мы приводим адаптированный перевод статьи The non-techie’s guide to servers Кеннена Чандрасегарана (Kannan Chandrasegaran), разработчика из компании Panopto. Просим обратить внимание, что статья рассчитана на новичков, которые мало знакомы с понятием серверной части приложения и серверов.
Из жизни офиса
Сложно быть «не-технарём» в ИТ-компании, уж поверьте! Маркетологи, менеджеры по продажам, бухгалтеры - не суть важно - время от времени они сталкиваются со своими технически подкованными коллегами. Это могут быть программисты или системные администраторы.... В любом случае, "не-технари" чувствуют себя так, будто им ампутировали важную часть мозга. Или они высадились на неизвестную планету с разумной негуманоидной жизнью. Или…Иногда, конечно, всё заканчивается благополучно. Вот, например, девушка-« », идёт по коридору. Ничто не предвещает беды: она направляется налево, вы – направо, и как можно быстрее… Нет, в этот раз не пронесло. Вы уже сидите с ней за столом, и пытаясь побороть неловкое молчание, спрашиваете: «А...чем именно ты занимаешься?». Она начинает рассказывать что-то, но вы не сразу врубаетесь, о чём она. Вроде бы и слова знакомые: пользовательский интерфейс, приложения, и - точно, Facebook - это сайт. Ага, там есть кнопочки, меню… Вы кое-как разобрались в хитросплетениях её работы, киваете ей на прощание и ваши пути расходятся в коридорах большого офиса.
Но рано или поздно вам не так повезёт: вы встретите инженера по серверам. Или бек-энд разработчика. Не зная в какие дебри сейчас попадёте, вы наивно задаёте тот же вопрос и... получаете абракадабру в ответ. Слышите уйму иностранных слов, а в голове пробегают мысли: «Прилично ли спросить, что такое API?», «Мы всё время используем «бэдэ» (DataBase), правда, что ли?», «Кто такой, чёрт побери, этот Джейсон (JSON)??». Ваш знакомый инженер пытается рассказать вам о серверах, но не понимает, насколько вам сложно понять его наполненную профессиональными терминами речь. Вероятно, вы уже слышали слово "сервер" раньше, но его употребляют в настолько разных контекстах, что осознать его значение крайне сложно. Что ж попробуем разобраться с этим термином.
Вниз по кроличьей норе
Когда обычный человек (в смысле, не программист или админ) использует приложение, всё, что он видит - это интерфейс, картинку, которая реагирует на какие-то очевидные (чаще всего) действия. На самом деле то, что пользователи понимает под «приложением» обычно - его фронт-енд, то есть, лицевая, часть, обёртка, с которой они взаимодействуют. А вот о том, что внутри, то есть о том, что заставляет приложение работать, пользователи знают крайне мало. Скажем, вы отправляете мне сообщение, например, по Whatsapp или Viber. Это выглядит так, будто сообщение идет с вашего смартфона на мой. Давайте посмотрим на этот процесс внимательнее. Скажем, вы отправляете мне сообщение, когда мой телефон выключен, а затем вы сами выключаете свой смартфон. И вот, я включаю свой телефон, и все-таки получаю ваше сообщение, хотя наши телефоны одновременно не работали. Похоже, мы что-то упустили! Это «что-то», пропущенный нами компонент - бек-энд или сервер.Говоря о фронт-энде и бек-энде, программисты обычно подразумевают разделение пользовательской части приложения от программной логики. Итак, фронт-энд (front-end) - это интерфейсная часть приложения, а бек-энд (back-end) - его серверная часть.
Серверы
По сути, сервер - это вычислительная машина, компьютер, который подсоединён к Интернету, и постоянно включён. Когда приложению требуется какая-либо информация, оно обращается к серверу. Когда приложению требуется связаться с другим пользователем приложения, именно сервер обеспечивает их взаимодействие. Термины сервер, бэк-энд и API (апи) часто используются как взаимозаменяемые.Хранилища или системы хранения данных
Основная задача сервера - хранение данных. Сюда входят файлы : фотографии, видео и документы. Сервер хранит их в структурированном виде, который похож на папки на вашем компьютере, таким образом они могут быть доступны приложениям. Также на сервере хранится информация . Все приложения содержат информацию важную для их работы.Вы можете представить такую информацию в виде набора таблиц. Например, приложению необходимо хранить информацию о пользователе и его пароле, чтобы могла пройти аутентификация. Ваше приложение может быть путеводителем по ресторанам, в этом случае сервер будет хранить информацию о каждом ресторане. Помимо самой информации сервер также записывает связи между данными. Например, пользователь лайкает ресторан в приложении на смартфоне, и сервер запоминает такую связь между рестораном и пользователем.
Это позволяет ответить на многие вопросы. Например:
- Сколько пользователей лайкнули этот ресторан?
- Какие рестораны нравятся этому пользователю?
- Блюда какой кухни нравятся сразу нескольким пользователям?
- могут хранить информацию
- могут хранить связи между данными
- могут получать запросы об информации и отвечать на них как единичными данными или набором данных, в зависимости от запроса.
Взаимодействие
Ключевая задача сервера - взаимодействие с приложением и другими серверами.Многие задачи приложения требуют взаимодействия с сервером. Например, если пользователь что-то ищет, поисковый запрос посылается на сервер и оттуда приходит результат. Если пользователь шлет сообщение другому пользователю, оно сначала приходит на сервер. А затем оттуда отправляется на приложение другого пользователя, чаще всего в виде отправленного уведомления. Интерфейсы, которые предоставляет сервер для того, чтобы приложения могли с ним взаимодействовать, обычно называются API . Ну а какие-то функции интерфейса можно сопоставить с конечными точками (endpoints), например, с поиском или авторизацией на сайте. Непосвященным такое взаимодействие может показаться странным. Двумя наиболее распространенными форматами взаимодействия являются JSON и XML.
XML слева, JSON справа На первый взгляд форматы выглядят трудночитаемыми. Важно понимать, что сервер - это просто компьютер, как ваш ноутбук или смартфон. Приложение на вашем телефоне принимает пользовательский ввод в голосовом или текстовом виде, с помощью распознавания голоса или касания к экрану. Приложение обрабатывает эту информацию, а затем дает ответ в виде изображения на экране. Смартфон -компьютер, который взаимодействует с человеком, поэтому ввод и вывод предоставляются в удобной для человека форме. Сервер - вычислительная машина, которая взаимодействует только с другими компьютерами. Человек воспринимает информацию благодаря таким вещам как: размер шрифта, цвет текста и форматирование. Но это ничего не значит для компьютера.Серверное приложение
Если вы хотите создать приложение, которое будет работать на вашем телефоне, вам также понадобится приложение, которое будет работать на сервере. Серверные приложения создаются с помощью серверных языков программирования и фреймворков, популярными вариантами которых являются Java , Ruby on Rails , Node.js , PHP , ASP.NET .Можно сказать, что API - это «двери» вашего сервера и приложение знает, что в них надо стучать. База данных хранит всю вашу информацию. А серверное приложение – это «мозг», который связывает все вместе. Оно получает и отвечает на запросы, которые поступают ему через API, добавляет и извлекает информацию из базы данных, и принимает решения. Например, когда пользовательское приложение отправляет информацию для входа, запрос поступает через API, правильная информация для входа хранится в базе данных. Задачей серверного приложения сравнить их и соответственно ответить приложению, используя API.
Аппаратное обеспечение
Когда вы слышите слово «сервер», скорее всего, вы представляете такую картинку: шкафы с мерцающими лампочками в закрытой комнате. Вероятно, для полноты картины, не хватает только Тома Круза, который спустится с потолка и что-нибудь крадёт. Многие большие компании владеют собственными серверами и целыми центрами обработки данных (те самые огромные комнаты с мерцающими шкафами). У Facebook и Google сотни серверов по всему миру. Когда вы руководите огромным сервисом с миллионами пользователей, содержание собственных серверов может быть значительно дешевле и это обеспечит более высокую производительность. Вместо того чтобы содержать свои собственные сервера многие разработчики используют облачные сервисы. Такие сервисы как Amazon Web Services, Azure и Digital Ocean предлагают возможность использования «виртуальных серверов». Эти сервисы владеют и обслуживают аппаратное обеспечение, а разработчик просто загружает на него серверное приложение. Некоторые провайдеры услуг предоставляют бекэнд как сервис, позволяя вам иметь простой бэкенд без необходимости писать серверное приложение самостоятельно.
Всем ли приложениям нужен бэкенд?
Большинство знакомых вам приложений, скорее всего, имеют бэкенд-компонент. Конечно, можно найти программы без серверной части. Например, некоторые приложения для продуктивности. Легкий способ выяснить есть ли у приложения бэк-енд выглядит так: Если ответ «нет», это означает что у приложения точно есть бекэнд-сервер.Надеюсь, у вас появилось понимание, что такое бек-энд приложения. Может быть, когда вы встретите своих знакомых-программистов в следующий раз, то сможете не только понять, о чем они говорят, но и использовать какого-нибудь чёртового «Джейсона» в вашей беседе.
