Настройка сервера: Как проходит настройка сервера

Как проходит настройка сервера

Что такое сервер? Зачем необходимо использовать сервер?

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

Почему выбирать, устанавливать и настраивать сервер должны профессионалы?

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

Готовы ли вы доверить не дешёвые работы по установке и настройке дорогого серверного оборудования и всю свою корпоративную информацию непрофессионалам в которых не уверены? Любые работы по установке и настройке сервера это сложный, многоэтапный процесс который требует тщательного и взвешенного подхода. Если вы хотите чтобы настроенный сервер работал стабильно и был помощником, а не проблемой, обратитесь к профессионалам, позвоните нам!

Как проходит настройка сервера?

1. Определение задач:

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

• Настройка прокси сервера.
• Настройка VPN сервера. VPN Server.
• Настройка почтового сервера. Настройка сервера почты.
• Настройка DNS сервера.
• Настройка SQL сервера. SQL Server.
• Настройка ISA сервера. ISA server.
• Настройка терминального сервера (настройка сервера терминалов).
• Настройка WEB сервера.
• Настройка файл сервера. Настройка ФТП сервера (ftp server).
• Настройка Active Directory (настройка AD).
• Подбор аппаратного решения.

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

2. Подбор программного обеспечения:

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

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

3. Установка сервера. Первичная настройка сервера:

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

4. Настройка серверных сервисов и служб. Тестирование сервера:

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

5. Обслуживание сервера:

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

Сколько времени занимает настройка и установка сервера?

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

Требования к помещению для установки сервера:

Установка сервера нуждается в подготовленном месте для установки. Установка сервера выполняется в дата-центре на хостинг или в специально оборудованном помещении в офисе. Установку серверов рекомендуют делать в стойку высотой 180-240 см. Данная установка позволяет максимально экономить пространство в помещении.

Компании, не обладающие достаточной площадью помещения, обычно выполняют установку сервера в Дата-центре.

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

Услуги предоставляемые нашей компанией по настройке серверного оборудования:

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

Linux (Линукс) – это обобщённое название Unix-подобных операционных систем, на основе одноимённого ядра. В настоящее время ОС Linux корректно функционирует практически на всех PC совместимых системах, чем обусловливается её растущая популярность.

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

Настройка сервера для хостинга | serveradmin.ru

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

Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «Administrator Linux. Professional» в OTUS. Курс не для новичков, для поступления нужно пройти .

Цели статьи

1. Рассказать о схеме построения приватного хостинга на базе выделенного сервера или серверов.
2. Подробно описать роль каждой виртуальной машины в составе хостинга.
3. Поделиться своим реальным опытом на тему настройки и сопровождения веб серверов.
4. Наполнить статью ссылками на свои материалы по заданной теме, чтобы можно было на практике повторить все описанное ниже.

Введение

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

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

• Frontend в виде проксирующего nginx.
• Backend сервер в связке с nginx + php-fpm либо Bitrixenv для сайтов на bitrix.
• Zabbix сервер для мониторинга.
• Elk Stack для хранения и анализа логов web сервера.

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

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

Так же, в случае необходимости, я отдельно разворачиваю виртуальные машины с Youtrack, Teamcity, Onlyoffice, Gitlab. Можно компактно разместить все необходимое для работы небольшой команды разработчиков.

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

1. В Kubernetes имеет смысл размещать только те проекты, которые изначально построены на основе микросервисов. WordPress и Bitrix в k8s размещать неудобно.
2. Размещение на собственных серверах дает прогнозируемую производительность и максимальное выгодное соотношение производительности к стоимости. То есть это банально дешевле облаков раза в 2-3.

Итак, разберем теперь отдельно каждую виртуальную машину. В качестве базовых систем я использую Centos 8, но это не принципиально. Используйте ту систему, что вам больше нравится. Это может быть и Debian, и Ubuntu.

Гипервизор для своего хостинга

В подавляющем большинстве случаев я использую виртуализацию на базе Proxmox. Выделенный сервер арендую у Selectel. В зависимости от бюджета и потребностей, это может быть простенький сервер из двух дисков на десктопном железе, либо полноценный сервер с железным рейд контроллером и постоянной ip-kvm панелью.

Если сервер без рейд контроллера, то используется софтовый рейд mdadm. Установка и настройка proxmox на софтовом рейде у меня подробно описана. У Selectel удобно выполнены базовые шаблоны для установки. Если я заказываю сервер, то сразу выбираю в качестве системы Debian на raid1. Установщик автоматически накатывает систему на mdadm. Остается только установить гипервизор. Самому разбивать диски и собирать mdadm не придется.

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

Если у вас только один внешний IP адрес, то на гипервизоре используются 2 сетевых интерфейса:

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

Если используются несколько IP адресов, которые нужно будет назначать разным виртуальным машинам, то сетевых интерфейса будет 3:

1. Реальная сетевая карта без настроек IP адреса.
2. Бридж vmbr1, в который будет включен сетевой интерфейс, в который приходит линк с внешними ip адресами. На этом бридже будет настроен реальный IP адрес самого гипервизора, если нет отдельного шлюза. Этот же бридж будет подключен к тем виртуальным машинам, где нужен внешний ip адрес.
3. Бридж vmbr0 для виртуальной сети виртуальных машин.

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

С гипервизором разобрались, переходим к следующему элементу web хостинга — frontend серверу.

Frontend сервер nginx

В качестве frontend сервера выступает Nginx, работающий в режиме proxy_pass. В контексте данного раздела я рекомендую 2 статьи на тему настройки Nginx — настройка проксирования и базовая настройка nginx.

В данном случае не обязательно использовать именно Nginx. В некоторых ситуациях более актуальным будет взять HAProxy. Но в общем случае подойдет Nginx. На frontend сервер будут поступать все внешние http запросы. На него будут проброшены порты 80 и 443. Расскажу, для чего использовать отдельный frontend сервер. Ведь можно обойтись и без него.

1. Удобство эксплуатации и обновления. К примеру, я хочу попробовать какую-то новую настройку — изменение ядра, модуля nginx и т.д. Я делаю копию frontend, настраиваю на нем все, что нужно и переключаю на него трафик. Если все в порядке, то оставляю в работе, либо переношу настройки на основной сервер. Если возникают какие-то проблемы, я просто переключаю проброс порта на старый сервер и все сразу начинает работать как прежде. В общем случае, frontend сервер очень маленький (20-30 гб под систему и логи).
2. На frontend удобно работать с внешними запросами — контролировать, обрабатывать, блокировать, предотвращая доступ к бэкенду с данными. Например, можно настроить ipset и блокировать отдельные страны. Можно выстроить простейшую защиту от ddos. Можно настроить отдельный модуль ModSecurity для Nginx. Когда у вас frontend отдельно, вам проще настраивать и обновлять компоненты, не боясь нарушить работу сайтов.
3. Frontend сервер аккумулирует все логи с внешних запросов и передает в ELK. Далее я покажу, как их удобно в автоматическом режиме сразу все передавать на хранение, а потом удобно анализировать.
4. В общем случае с отдельным frontend сервером безопаснее. Все внешние запросы приходят к нему. Многие зловреды (как и легальные компоненты и плагины) не понимают, как работать на бэкенде, который стоит за frontend. Это как плюс так и минус в некоторых случаях, так как усложняется эксплуатация. Особенно хлопотно с битриксом, так как у него много сервисов и проверок, которые напрямую стучатся по внешнему ip домена и не понимают, что делать, когда попадают на фронтенд. Но это все решаемо.

На frontend настраиваются бесплатные сертификаты от Let’s Encrypt. Так как весь трафик от фронта до бэка крутится в рамках одного гипервизора, смысла передавать его в шифрованном виде нет. Так что на backend он идет по http.

С frontend я отправляю в ELK логи запросов только к php скриптам. Именно они представляют для меня полезную информацию, так как позволяют оценить скорость работы сайта. Информация от отдачи статики лично мне не нужна. В общем случае, я ее не собираю, а включаю отдельно по мере необходимости. Это позволяет не раздувать лог файлы. Чем меньше их объем, тем удобнее и быстрее с ними работать.

Backend сервер nginx, apache, php

Про бэкенд сервер рассказывать особо нечего. Он настраивается в зависимости от потребностей проекта. В общем случае для php сайтов это будет либо настройка nginx + php-fpm, либо apache + php. Как я уже говорил, бэкендов может быть несколько. Если вы web студия или какое-то агенство, которое само хостит сайты клиентов, то у вас может быть как классический web сервер php, так и bitrixenv для размещения битрикс сайтов. А они сейчас очень популярны. Почти все интернет магазины, с которыми я работал, были на битриксе. Плюс коробки с bitrix24 иногда покупают. Если сотрудничаете с малым или среднем бизнесом, без битрикса скорее всего не обойтись. Я его хоть и не люблю, но работать приходится.

В общем случае на backend я не настраиваю ssl, но бывают исключения или различные ошибки. Вот примеры таких ошибок в работе типовых php сайтов:

У Битрикса тоже есть похожие ошибки, но я их не зафиксировал в статьях.

Я каждый сайт размещаю в отдельной директории, например /mnt/web/sites/site.ru. В этой директории уже свои поддиректории www, logs, php_sessions и т.д. Владелец каждого сайта — отдельный системный пользователь. От этого пользователя работает php-fpm пул, который обслуживает только этот сайт. Для каждого пользователя настроен sftp доступ к конкретному сайту. Каждый сайт имеет доступ только к своей базе mysql или postgresql.

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

Мониторинг сайтов и серверов

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

1. Мониторинг mdadm или железного контроллера. По последним, к сожалению, у меня нет статей, но в целом проблем с настройкой не возникает. У меня всегда гуглились подходящие решения. Если у сервера есть idrac, ilo, ipmi, можно с них брать нужные данные.
2. Если есть доступ к смарту дисков, то настраиваю мониторинг smart. Очень рекомендую это делать, чтобы в случае выхода из строя какого-то диска, у вас была полная информация о нем, чтобы передать ее в службу технической поддержки для замены.
3. Мониторинг подключений по ssh. Мне сразу приходит уведомление, если кто-то подключается к серверу по ssh. Если доступ есть не только у меня, то обязательно это настраиваю. Сильно упрощает жизнь и готовит к проблемам 🙂 Если доступ только у меня, то это небольшая защита и возможность быстро среагировать на несанкционированный доступ, хотя в реальности у меня ни разу такого не было.
4. Мониторинг веб сервера, в данном случае frontend и backend. Иногда мониторинг бэка не делаю. Реально не так уж часто он нужен, хотя кажется, что полезно получать все метрики. Но лично моя практика такова, что они мне на деле чаще всего не нужны.
5. Мониторинг сайта. Это одна из самых главных метрик, так как напрямую отвечает на вопрос, все ли у нас в порядке. Если сайт не работает или не доступен, то это наивысший приоритет проблемы. Так как мониторинг у нас локальный, он не дает полную картину происходящего, нужен еще один внешний. О нем подробнее расскажу далее. Локальный мониторинг сразу определяет, к примеру, если у нас упал backend и вместо страницы сайта видим 500-ю ошибку nginx. Или что-то еще. В общем, важная штука, рекомендую внимательно отнестись к мониторингу сайта. Рекомендую к нему обращаться напрямую через внутреннюю сеть гипервизора по локальному ip фронта. Для этого надо либо в host файл виртуалки с zabbix добавить все сайты по локальному ip, либо завести свой локальный dns сервер. Обычно я это делаю, если используется отдельная виртуальная машина под шлюз.
6. Мониторинг делегирования домена и ssl сертификата. Штука не обязательная, настраивается по желанию. Если делегирование не так критично, так как регистраторы завалят напоминаниями на почту, то мониторинг ssl сертификатов рекомендую сделать. Их часто забывают продлить или возникают технические ошибки при работе с автопродлением Let’s Encrypt.
7. Я всегда настраиваю мониторинг бэкапов в том или ином виде. Он сильно зависит от конкретной ситуации, от данных, от места хранения бэкапов и т.д. Готовых решений нет, приходится импровизировать на месте. Но если не настрою мониторинг бэкапов, не могу спать спокойно. Бэкапы периодически разворачиваю вручную и проверяю. Это сильно ограничивает количество клиентов, с которыми могу сотрудничать, так как труд ручной. Но это меня много раз спасало. Так что не пренебрегаю.
8. Если есть почтовый сервер, настраиваю мониторинг postfix. За почтовым сервером рекомендую внимательно следить, особенно за очередью и количеством отправленных сообщений. Иногда учетки ящиков утекают в сеть и сервер начинает массово спамить. Если вовремя это не заметить и не остановить, можно залететь в спам листы и надолго там засесть. Это может парализовать работу того же интернет магазина, так как без почты он перестает нормально функционировать.

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

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

Хранение логов в ELK Stack

Я складываю все логи в elasticsearch. У меня есть статья про установку и настройку ELK Stack. Недавно я обновил инструкцию по установке, но скрины оставил старые. Очень хлопотно их заменять. Сам процесс установки отражен правильно, так как я регулярно пользуюсь своей статьей. У меня есть несколько примеров того, как можно анализировать логи различных сервисов.

В контексте данной статьи по настройке приватного хостинга нас будет интересовать сбор web логов и их анализ:

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

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

Тут же можно сделать выборку по медленным запросам, по запросам с определенных ip адресов, посмотреть запросы с различными кодами ошибок и т. д. В общем, без такого дашборда я ощущаю себя слепым. Я не понимаю, как понять, что с сайтом все в порядке, или наоборот узнать, какие у него проблемы, если у тебя нет под рукой подобной информации. Сайт может начать сыпать пятисотыми ошибками, а тебе надо как-то вручную грепать access log и пытаться понять, проблема единичная или масштабная. А тут все под рукой.

Я так привык в ELK, что на сервера почти не хожу. Все логи собираю в нем (обязательно системные) и там же просматриваю. Плюс к этому мониторинг и управление через ansible, но об этом позже. Ходить на сервера по ssh практически нет необходимости.

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

На фронте у меня логи всех сайтов складываются в одну директорию /var/log/nginx и оттуда единым шаблоном уходят в filebeat, а с него в logstash и далее в elasticsearch в один общий индекс, который бьется по дням. Раньше я каждый сайт отправлял в отдельный индекс, но со временем понял, что это не удобно. Так приходится для каждого индекса создавать свои визуализации и дашборды. Когда сайтов много это хлопотно, хотя и можно автоматизировать, но большого смысла нет на моих масштабах.

Сейчас я собираю все в один индекс, делаю единый dashboard и в нем уже с помощью фильтров просматриваю данные по разным сайтам. Я вывел в лог nginx информацию об имени виртуального домена. Это удобно и быстро настраивается. Для каждого нового сайта не надо вообще ничего делать. Filebeat автоматом забирает его логи. С помощью фильтра в Kibana просматривается информация в логах.

Почтовый сервер и шлюз

На настройке почтового сервера и шлюза для нужд хостинга подробно останавливаться не хочется. Статья и так очень большая получается. К тому же тут особых нюансов нет. Нужен обычный шлюз и обычный почтовый сервер. Можно взять готовую сборку, к примеру, iredmail или zimbra. Я иногда использую первый. Но чаще всего настраиваю все сам на базе postfix + dovecot + postfixadmin + roundcube. Так же рекомендую свою статью-рассуждение на тему, какой почтовый сервер выбрать.

В качестве шлюза так же можно взять либо готовую сборку, к примеру, на базе pfsense, clearos или чего-то подобного, либо настроить все самому. Я обычно настраиваю сам, так как не люблю зоопарк из систем. Мне нравится единообразие. Так удобнее управлять инфраструктурой, поэтому все собираю сам. Вот пример настройки шлюза на centos 7. Статья давно написана, на полностью актуальна. Ничего принципиально не поменялось.

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

Если используются несколько дедиков в проекте, не объединенных в локальную сеть в рамках ЦОД, я их объединяю с помощью openvpn через интернет.

Backup сайтов

Для бэкапа я предпочитаю арендовать виртуальные машины в ruvds. К ним можно подключить большие диски — от 500 Гб и больше.

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

Если собираетесь делать бэкапы виртуальных машин, то настраивайте nfs сервер, подключайте его по vpn к гипервизору и настраивайте как отдельное хранилище для бэкапов. Штатным средством proxmox делайте регулярные бэкапы. В качестве nfs сервера отлично подходят виртуалки ruvds, так как там полноценная операционная система.

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

Так же я настраиваю дублирование бэкапов на s3 подобные хранилища с помощью rclone. Например, в selectel. Похожие хранилища есть у mail.ru и yandex.cloud. Облачные сервисы mail.ru я в настоящее время тестирую. Возможно будут статьи по этому поводу.

Я обычно делаю 3 контейнера в s3 с именами day, week, month и настраиваю правила хранения в них:

• day — 14 дней
• week — 31 день
• month — бессрочно

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

Управление хостингом

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

Сейчас просто не работаю с панелями вообще. Если кто-то предлагает взять на поддержку сервер с панелью управления хостингом (ispmanager, plex, vestacp), сразу отказываюсь. Я не могу гарантировать стабильную работу сайтов на них.

Раньше я писал bash скрипты для быстрого добавления сайта или настройки системы. Когда сайтов не много, создавал их руками. Сейчас я все стараюсь делать с помощью ansible. В паблик пока не готов выдать свои наработки. Их оформить отдельный труд. Нужно для начала хотя бы обзорную статью про ansible написать. Черновик уже год как написан, но не хватает времени оформить в полноценную статью.

Перечислю основные моменты, которые нужно автоматизировать:

• При добавлении виртуальной машины базовые настройки системы, подключение к мониторингу.
• При создании сайта — создание конфига nginx на фронте и бэке, запрос на сертификат, создание директорий и системного пользователя для сайта, создание php-fpm пула, настройка ротации логов, создание базы данных и пользователя, доступ пользователя по sftp.
• Поправить скрипт создания бэкапов. Создаю их bash скриптом. Есть мысли тоже через ansible делать, но пока не прорабатывал тему.
• Добавление мониторинга сайта в Zabbix. Пока не реализовал. Надо делать через api заббикса. Руки не дошли. С автоматизацией веб проверок в заббиксе пока все плохо.

Это основное. Может что-то забыл. Первое время все делал топорно единой yaml лапшой файла плейбука. Последнее время все переделываю с использованием шаблонов, ролей, задач, хендлеров, инвентаря и т.д. Стараюсь использовать ansible правильно.

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

Например, при настройке firewall я всегда опасаюсь применять изменения в правилах. Вдруг где-то ошибся и что-то пойдет не так. Отрубится какой-то сервис или еще хуже — потеряю доступ к серверу. А когда у тебя есть шаблон и готовый плейбук по добавлению правил или заливки готового набора правил из шаблона, тебе достаточно проверить только переменные, чтобы в них не было ошибок. Далее прогнать на всякий случай плейбук в режиме check, а потом применить, если все в порядке.

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

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

Базовые рекомендации по настройке своего хостинга

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

1. Закрывайте с помощью firewall все не публичные доступы — ssh, панель управления proxmox, phpmyadmin и т.д. Я долгое время не делал этого, так как боялся не получить доступ в экстренной ситуации, когда я не смогу зайти через доверенный ip адрес. На практике это не было никогда проблемой. Обычно разрешаю к подключению свой статический ip адрес и 2 vpn сервера тоже со статичными внешними адресами.
2. Настраивайте мониторинг всех критичных вещей — состояние рейда, актуальность бэкапов, подключения по ssh к  серверам и т.д. Не делайте много уведомлений — только реально важные вещи. Если будет спам от мониторинга, толку от него становится мало. Делайте повторяющиеся уведомления для некритичных событий, которые часто откладываешь и забываешь исправить.
3. Если занимаетесь работами по ускорению работы сайтов, можно в отдельной виртуальной машине настроить локальную версию сервиса webpagetest для объективной оценки скорости сайта без внешних сетевых задержек.
4. Когда обновляете систему на виртуальной машине, сделайте ее snapshot. После установки, если все в порядке, не забудьте его удалить. Это простое правило может очень сильно выручить в случае нештатной ситуации. Кстати, обновления я всегда делаю вручную, не через ansible или какие-то еще средства автоматизации. Если нет полного дублирования функционала с автоматическим переключением на работающий сервис, предпочитаю вручную контролировать установку обновлений. К сожалению, не такая уж и редкость, когда обновление что-то ломает. Пример — elk stack или bitrixenv. Если обновление прошло без ошибок — это удача. Обычно что-то ломается.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

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

Если у вас есть желание получить себе подобный сервер или набор серверов, пишите примерное тех задание на почту. Адрес есть в разделе Контакты.

Онлайн курс по Linux

Если у вас есть желание освоить операционную систему Linux, не имея подходящего опыта, рекомендую познакомиться с онлайн-курсом Administrator Linux. Basic в OTUS. Курс для новичков, адаптирован для тех, кто только начинает изучение Linux. Обучение длится 4 месяца.

Что даст вам этот курс:

• Вы получите навыки администрирования Linux (структура Linux, основные команды, работа с файлами и ПО).
• Вы рассмотрите следующий стек технологий: Zabbix, Prometheus, TCP/IP, nginx, Apache, MySQL, Bash, Docker, Git, nosql, grfana, ELK.
• Умение настраивать веб-сервера, базы данных (mysql и nosql) и работа с сетью.
• Мониторинг и логирование на базе Zabbix, Prometheus, Grafana и ELK.
• Научитесь командной работе с помощью Git и Docker.

Смотрите подробнее программу по .

Помогла статья? Подписывайся на telegram канал автора

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Настройка выделенного сервера для работы сайта под управлением HostCMS / Хабр

В «жизни» практически любого веб-проекта – будь то небольшой интернет-магазин или сайт набирающего популярность бара – рано или поздно случается момент, когда не хватает ни возможностей и ресурсов shared-хостинга, ни средств для тотальной реорганизации архитектуры приложения. Несколько лет назад, когда я ещё работал в небольшой веб-студии, мне частенько приходилось наблюдать такую картину. Практически во всех подобных случаях принималось одно и то же решение – аренда выделенного сервера и перенос на него проекта в том виде, в котором он есть. В то время в сети было доступно немало статей по настройке серверов с Linux на борту. Причём практически все они были не самого лучшего качества и зачастую содержали настолько вредные советы, что господин Остер мог бы стоя аплодировать авторам тех материалов.

«Всё это дела давно минувших дней» – так я думал ещё совсем недавно, пока ко мне не обратился мой давний приятель за помощью в решении аналогичной проблемы. Как оказалось, ситуация с тех пор сильно не изменилась: нужный раздел документации практически не обновился, сами разработчики в основном советуют воспользоваться shared-хостингом от своих партнёров, а толкового материала, учитывающего нюансы миграции на выделенный сервер проекта на HostCMS, так и не нашлось. Мне нравится сама CMS, поэтому я решил исправить это упущение. Если интересно – добро пожаловать под кат.

Прежде всего оговорюсь. В этой статье я не буду рассматривать вопросы выбора хостинг-провайдера – с этим, я думаю, вы справитесь сами. В качестве серверной ОС выбрана Ubuntu Server 14.04 как одна из наиболее дружелюбных к пользователю. Я предполагаю, что вы обладаете минимальным набором знаний для работы в Linux. К сожалению, здесь вы не найдете тонкой настройки PAM модуля для установки пользовательских лимитов на обращение к файлам и т.п. – если вы ищите такой материал, то скорее всего эта статья будет для вас скучна.

Первые шаги

Итак, у нас есть выделенный сервер и данные для доступа к нему по ssh. Правило первое, оно же главное, старайтесь избегать постоянной работы от имени привилегированного пользователя. Во время первого же сеанса создайте собственную учетную запись и установите для нее пароль. Например, так:

useradd user_name -s /bin/bash -U -m -G sudo
passwd user_name 

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

Установка необходимого ПО

nginx

В качестве HTTP-сервера будет использоваться nginx. Думаю, что в представлении он не нуждается. Устанавливать его будем из репозитория, любезно развёрнутого командой разработчиков. Для этого необходимо получить ключ, которым подписаны установочные пакеты:

# иногда происходит неведомая фигня с добавлением ключей непосредственно из STDOUT
# поэтому сначала ключ сохраняем в файл и только потом добавляем
wget http://nginx.org/keys/nginx_signing.key 
sudo apt-key add nginx_signing.key
rm nginx_signing.key

И обновить список источников пакетов, добавив в файл /etc/apt/sources.list строки:

# 12.04 = precise
# 14.04 = trusty
deb http://nginx.org/packages/ubuntu/ trusty nginx
deb-src http://nginx.org/packages/ubuntu/ trusty nginx

После этого обновляемся и устанавливаем nginx:

sudo aptitude update && sudo aptitude upgrade -y
sudo aptitude install nginx

Чтобы задать лимиты на количество открываемых пользователем http-сервера файлов, нужно добавить в /etc/security/limits.conf строки:

nginx        hard    nofile  32768
nginx        soft    nofile  32768

Точные цифры следует подбирать, исходя из конфигурации вашего сервера. Активируется модуль лимитов добавлением следующей строки в /etc/pam.d/common-session:

session required     pam_limits.so

Проверить, что лимиты установились можно следующей командой:

sudo su nginx --shell /bin/bash --command "ulimit -a"

PHP

HostCMS требует, чтобы были включены следующие модули php: curl, gd, xslt и, естественно, mysql. Кроме того, обратите внимание, что теперь пакет php5-json не является виртуальным и его нужно устанавливать отдельно. Помимо прочего подключим модуль кеширования опкода xcache. В качестве SAPI (режим запуска интерпретатора) будем использовать PHP-FPM, однако, чтобы иметь возможность выполлять некоторые скрипты по расписанию будет установлен еще и PHP-CLI.

sudo aptitude install php5-common php5-fpm php5-cli php5-curl php5-gd php5-mysql php5-xsl php5-json php5-xcache

MySQL

Установка MySQL довольная проста. Несколько раз установщик запросит у вас пароль для root’а сервера баз данных, можете смело оставлять его пустым — мы сменим его позже, с помощью утилиты mysql_secure_installation. При ее запуске ответьте, что хотите сменить пароль root’a, удалить тестовую БД и тестовых пользователей и обновить права на таблицы службной БД.

sudo aptitude install mysql-server
sudo mysql_secure_installation

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

Настройка загрузки файлов

В качестве протокола передачи файлов я предлагаю использовать SSH FTP (SFTP). Во-первых, он безопаснее обычного ftp, так как данные будут передаваться в зашифрованном виде. Во-вторых, не придется устанавливать дополнительное ПО: все что нужно — ssh-сервер — у нас уже есть. А минусов практически никаких — все современные IDE и клиенты загрузки данных умеют работать с этим протоколом.
Чтобы определить, кому можно подключаться по sftp, создадим дополнительную группу пользователей, например, sftp:

sudo groupadd sftp

И активируем передачу данных, добавив в конец файла /etc/ssh/sshd_config строки:

Match Group sftp
	ChrootDirectory    %h
	ForceCommand       internal-sftp
	AllowTcpForwarding no

Подготовка файловой системы

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

sudo mkdir -p -m 755 /var/www/data
sudo mkdir -m 777 /var/www/tmp

Затем укажем, что при следующей загрузке, в эту папку будет смонтирована tmpfs. Добавим в /etc/fstab:

tmpfs	/var/www/tmp/	tmpfs	defaults,noatime,nosuid,nodev,noexec,mode=1777,size=128M	0	0

Стоит заметить, что некоторые редакции HostCMS имеют встроенный алгоритм кеширования ответов в файлы. Если вы используете одну из таких редакций имеет смысл примонтировать tmpfs к директории кеша самой CMS.

Настройка виртуальных хостов

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

Заведение пользователя хоста

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

sudo useradd -b /var/www/data -s /usr/lib/sftp-server -m -U -G sftp example.com
sudo passwd example.com
sudo su example.com --shell /bin/bash --command "mkdir -m 0755 ~/data ~/log && mkdir -m 0777 ~/tmp"

Для корректной работы chroot’а нужно сделать root’a владельцем домашнего каталога этого пользователя:

cd /var/www/data
sudo chown root:root example.com

Заведение пула PHP-FPM

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

[example.com]
user = example.com
group = example.com

listen = /var/run/php5_example.com.sock
listen.backlog = 4096
listen.owner = nginx
listen.group = nginx
listen.mode = 0660

process.priority = 0
chdir = /

pm = dynamic
pm.max_children = 64
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 16
pm.process_idle_timeout = 60s;
pm.max_requests = 256

access.log = /var/www/data/example.com/log/php.access.log
access.format = "%R # %{HTTP_HOST}e # %{HTTP_USER_AGENT}e # %t # %m # %r # %Q%q # %s # %f # %{mili}d # %{kilo}M # %{user}C+%{system}C"

slowlog = /var/www/data/example.com/log/php.slow.log
request_slowlog_timeout = 2s
request_terminate_timeout = 300s

php_admin_flag[display_errors]     = off
php_admin_flag[log_errors]         = on
php_admin_value[error_log]         = /var/www/data/example.com/log/php.error.log
php_admin_value[memory_limit]      = 32M
php_admin_value[open_basedir]      = /var/www/data/example.com/:.
php_admin_value[upload_tmp_dir]    = /var/www/data/example.com/tmp
php_admin_value[session.save_path] = /var/www/data/example.com/tmp

Создание конфига виртуального хоста

В файле настройки хоста nginx вам нужно будет указать доменное имя сайта, путь для записи логов доступа и адрес юникс-сокета, который слушает php-fpm. Для обработки запросов к несуществующим файлам будем использовать именованный location — таким образом мы будем эмулировать работу mod_rewrite для Apache2. Перед тем, как отдавать на обработку скрипт нашему бэкэнду, проверяем его существование. Это позволить избежать проблемы, описанной здесь. Для того, чтобы снизить нагрузку на сайт от незарегистрированных пользователей, будем использовать кеширование на стороне nginx. Для этого создадим конфигурационный файл /etc/nginx/conf.d/cache со следующим содержимым:

    fastcgi_cache_path  /var/www/tmp/cache levels=1:2 keys_zone=cache:32m max_size=128m;
    fastcgi_temp_path   /var/www/tmp/proxy 1 2;

    fastcgi_ignore_headers  Expires Cache-Control;

    fastcgi_cache_lock          on;
    fastcgi_cache_lock_timeout  60s;
    fastcgi_cache_use_stale     error timeout updating invalid_header;

    fastcgi_cache_bypass  $cookie_PHPSESSID;
    fastcgi_no_cache      $cookie_PHPSESSID;

    fastcgi_cache_key  $scheme$host$request_uri;

А затем подключим его в конфиге виртуального хоста.Пример конфига хоста nginx

server {
    listen       80;
    server_name  example.com www.example.com;

    access_log   /var/www/data/example.com/log/nginx.access.log  main;
    error_log    /var/www/data/example.com/log/nginx.error.log;

    root         /var/www/data/example.com/data;

    error_page  404  /404/;

    location / {
        index  index.html index.php;
        try_files $uri $uri/ @hostcms;
    }

    # php скрипты отдаем в php-fpm, предварительно проверяя их существование
    location ~ \.php$ {
        try_files $uri =404;

        fastcgi_pass   unix:/var/run/php5_example.com.sock;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
        include        /etc/nginx/conf.d/cache;
    }

    # все запросы, для которых не нашлось файлов, переадресуются на index.php
    location @hostcms {
        fastcgi_pass   unix:/var/run/php5_example.com.sock;
        fastcgi_param  SCRIPT_FILENAME  $document_root/index.php;
        include        fastcgi_params;
        include        /etc/nginx/conf.d/cache;
    }

Создание базы данных сайта

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

CREATE USER 'example_com'@'localhost' IDENTIFIED BY 'ВашСуперСтойкийПароль';
GRANT USAGE ON * . * TO 'example_com'@'localhost' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;
CREATE DATABASE IF NOT EXISTS example_com_db DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
GRANT ALL PRIVILEGES ON example_com_db . * TO 'example_com'@'%';

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

use example_com_db;
source ПутьДоДампаБазыДанных;

Настройка резервного копирования и ротации логов

Если вы всё сделали правильно, то у вас уже должно быть полностью настроенное окружение для запуска вашего проекта. Остаются два последних по списку, но не по значимости, шага — настройка резервного копирования и ротации логов. В качестве инструмента для создания бэкапов я рекомендую использовать backup-manager. На хабре есть отличная статья про него, поэтому подробно останавливаться на нём не будем.

Для осуществления ротации логов нам нужно всего лишь создать правильный конфиг для утилиты logrotate.

Например, такой

/var/www/data/example.com/log/nginx*.log {
    weekly
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 640 root root
    sharedscripts
    postrotate
        [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
    endscript
}

/var/www/data/example.com/log/php*.log {
    weekly
    missingok
    rotate 52
    compress
    delaycompress
    notifempty
    create 640 root root
    postrotate
        invoke-rc.d php5-fpm reopen-logs > /dev/null
    endscript
}

Вместо заключения

Пожалуй, это всё, что я хотел сказать.
Возможно, кто-то сочтёт статью не слишком актуальной ввиду засилия панелей управления хостингом. Хотя, на мой взгляд, они хороши для массового предоставления услуг и совершенно не годятся, когда речь заходит о затачивании настроек сервера под конкретный проект.
Другие посчитают её немного сумбурной. Не исключено, что это и так: в статье я только попытался отразить свой путанный опыт в области серверного администрирования.
В любом случае, буду рад, если этот материал поможет кому-то. Замечания и дополнения приветствуются.

Как установить сервер на Windows

Чаще всего используются локальные серверы Denwer (джентльменский набор веб-разработчика), Xampp и Open Server — все три бесплатны.

Первый (Denwer) прошёл проверку временем и любим многими специалистами. Однако он уже достаточно давно не поддерживается разработчиками, поэтому придётся самостоятельно обновлять некоторые модули — например, версию PHP и СУБД (система управления базами данных).

Также сам он не совсем удобен: интерфейс установщика — консоль, а все настройки нужно вносить в специальные файлы с помощью «Блокнота».

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

В этой статье мы рассмотрим Open Server. Его преимущества:

• Не требует установки — достаточно скачать и распаковать архив.
• Удобные настройки — можно открыть меню и выбрать всё, что нужно.
• Обновления — регулярно выходят новые версии.

Главный недостаток, пожалуй, — большой вес:

Почти 900 МБ тут занимают версии PHP:

Их можно оставить, чтобы потом в настройках выбрать любую версию и писать на ней. Или удалить, чтобы освободить место. То же самое касается и СУБД:

Тут уже занято около 5 ГБ, поэтому можно смело удалять то, что вы не будете использовать. Например, я могу избавиться от всего, кроме MariaDB 10.3 и PHP 7.3.

Xampp весит гораздо меньше, но и выбор версий там скуднее (в основном последние). Также придётся использовать MySQL или самостоятельно настраивать другую СУБД. В принципе, вы можете выбрать и его — он используется так же, как Open Server, а установка немногим сложнее.

Настройка сервера

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

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

Как делается настройка сервера?

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

Прокси сервер

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

VPN сервер (VPN Server)

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

Почтовый сервер

Электронная почта на сегодняшний день является быстрым, надежным и простым средством взаимосвязи офисных сотрудников с внешним миром. Но главная проблема в данной сфере – наличие спама, на который приходится 80% от всего объема трафика электронных писем. Наличие спама приводит к потере писем от действительных или потенциальных клиентов, а также к занесению бесплатных почтовых серверов в черные списки (black листы). Наличие собственного почтового домена является гарантией того, что адресат в обязательном порядке получит отправленное ему письмо, а почта, отправленная вашими сотрудниками, не будет подвергаться подозрению. Установка почтового сервера подразумевает настройку спам фильтра, способного справиться с подавляющим большинством спама.

DNS сервер

Настройка DNS сервера – это неотъемлемая составляющая настройки почтового сервера и настройки active directory. Кроме того, использование данного типа сервера необходимо для повышения простоты и удобства работы сотрудников офиса.

SQL сервер (SQL Server)

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

ISA сервер (ISA server)

Такой гибкий и мощный инструмент, как ISA сервер, применяется для защиты корпоративных сетей от различного рода внешних угроз, а также для ограничения доступа пользователей сети к внешним ресурсам. ISA сервера обладают обширным функциональным набором и отличаются важностью выполняемых функций, что требует наличия специальных навыков для его детальной настройки. Максимальной эффективности работа ISA достигает в сочетании с RRaS сервером и microsoft active directory. Использование такого сочетания способствует решению таких распространенных задач, как защита сети от внешних угроз, ограничение доступа к нежелательным интернет-ресурсам и организация VPN доступа в удаленном режиме.

Терминальный сервер (настройка сервера терминалов)

Настройка терминального сервера выполняется при необходимости лицензирования организации, снижения расходов и оптимизации работы предприятий. Наибольшей популярностью пользуется работа сервера терминалов в сочетании с приложениями 1С, что объясняется простотой в применении, экономической выгодой и значительному снижению нагрузок на локальную сеть. Для подключения пользователей к такому серверу используется удаленный рабочий стол Windows – стандартный компонент ОС. Таким образом, работа с 1С осуществляется так же, как на собственном рабочем столе, что исключает необходимость установки клиентской части приложений на каждую рабочую станцию. Подобный подход позволяет снизить нагрузку на сеть и не требует загрузки базы 1С на ПК и обратно.

WEB сервер

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

Файл сервер. ФТП сервер (FTP server)

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

Настройка AD (Active Directory)

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

Установка и первичная настройка сервера

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

Настройка служб и сервисов, тестирование сервера

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

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

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

Преимущества заказа установки и настройки серверов у нас

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

Шаг 2. Настройка сервера удаленного доступа

• 
  08.08.2020
• Чтение занимает 7 мин

В этой статье

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

В этом разделе описывается настройка параметров клиента и сервера, необходимых для удаленного управления клиентами DirectAccess.This topic describes how to configure the client and server settings that are required for remote management of DirectAccess clients. Прежде чем приступать к развертыванию, убедитесь, что выполнены шаги по планированию, описанные в разделе Шаг 2. Планирование развертывания удаленного доступа.Before you begin the deployment steps, ensure that you have completed the planning steps that are described in Step 2 Plan the Remote Access Deployment.

Примечание

В этом разделе приводятся примеры командлетов Windows PowerShell, которые можно использовать для автоматизации некоторых описанных процедур.This topic includes sample Windows PowerShell cmdlets that you can use to automate some of the procedures described. Дополнительные сведения см. в разделе Использование командлетов.For more information, see Using Cmdlets.

Установка роли удаленного доступаInstall the Remote Access role

Необходимо установить роль удаленного доступа на сервере в Организации, который будет использоваться в качестве сервера удаленного доступа.You must install the Remote Access role on a server in your organization that will act as the Remote Access server.

Установка роли удаленного доступаTo install the Remote Access role

Установка роли удаленного доступа на серверах DirectAccessTo install the Remote Access role on DirectAccess servers

1. На сервере DirectAccess в консоли диспетчер сервера на панели мониторингащелкните Добавить роли и компоненты.On the DirectAccess server, in the Server Manager console, in the Dashboard, click Add roles and features.

2. Нажмите кнопку Далее трижды, чтобы перейти на страницу выбора роли сервера.Click Next three times to get to the server role selection screen.

3. В диалоговом окне Выбор ролей сервера выберите Удаленный доступ, а затем нажмите кнопку Далее.On the Select Server Roles dialog, select Remote Access, and then click Next.

4. Нажмите кнопку Далее три раза.Click Next three times.

5. В диалоговом окне Выбор служб ролей выберите DirectAccess и VPN (RAS) , а затем щелкните Добавить компоненты.On the Select role services dialog, select DirectAccess and VPN (RAS) and then click Add Features.

6. Выберите Маршрутизация, выберите прокси-служба веб приложения, щелкните Добавить компоненты, а затем нажмите кнопку Далее.Select Routing, select Web Application Proxy, click Add Features, and then click Next.

7. Нажмите кнопку Далее, а затем щелкните Установить.Click Next, and then click Install.

8. В диалоговом окне Ход установки убедитесь в успешном завершении установки, а затем нажмите кнопку Закрыть.On the Installation progress dialog, verify that the installation was successful, and then click Close.

Эквивалентные команды в Windows PowerShell Windows PowerShellWindows PowerShell equivalent commands

Следующие командлеты Windows PowerShell выполняют ту же функцию, что и предыдущая процедура.The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Вводите каждый командлет в одной строке, несмотря на то, что здесь они могут отображаться разбитыми на несколько строк из-за ограничений форматирования.Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

Install-WindowsFeature RemoteAccess -IncludeManagementTools

Настройка типа развертыванияConfigure the deployment type

Существует три параметра, которые можно использовать для развертывания удаленного доступа из консоли управления удаленным доступом.There are three options that you can use to deploy Remote Access from the Remote Access Management console:

• DirectAccess и VPN;DirectAccess and VPN

• только DirectAccess;DirectAccess only

• только VPN.VPN only

Примечание

В этом руководством в примерах процедур используется метод развертывания только DirectAccess.This guide uses the DirectAccess only method of deployment in the example procedures.

Настройка типа развертыванияTo configure the deployment type

1. На сервере удаленного доступа откройте консоль управления удаленным доступом: на начальном экране введите, введите консоль управления удаленным доступоми нажмите клавишу ВВОД.On the Remote Access server, open the Remote Access Management console: On the Start screen, type, type Remote Access Management Console, and then press ENTER. Если появится диалоговое окно контроля учетных записей, подтвердите, что отображаемое в нем действие именно то, которое требуется, и нажмите кнопку Да.If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

2. В средней области консоли управления удаленным доступом щелкните Запустить мастер настройки удаленного доступа.In the Remote Access Management Console, in the middle pane, click Run the Remote Access Setup Wizard.

3. В диалоговом окне Настройка удаленного доступа выберите DIRECTACCESS и VPN, только DirectAccess или только VPN.In the Configure Remote Access dialog box, select DirectAccess and VPN, DirectAccess only, or VPN only.

Настройка клиентов DirectAccessConfigure DirectAccess clients

Чтобы настроить клиентский компьютер для использования DirectAccess, он должен принадлежать выбранной группе безопасности.For a client computer to be provisioned to use DirectAccess, it must belong to the selected security group. После настройки DirectAccess подготавливается клиентские компьютеры в группе безопасности для получения объектов групповая политика DirectAccess (GPO) для удаленного управления.After DirectAccess is configured, client computers in the security group are provisioned to receive the DirectAccess Group Policy Objects (GPOs) for remote management.

Настройка клиентов DirectAccessTo configure DirectAccess clients

1. В средней области консоли управления удаленным доступом в разделе Этап 1. Удаленные клиенты щелкните Настроить.In the middle pane of the Remote Access Management console, in the Step 1 Remote Clients area, click Configure.

2. В мастере установки клиента DirectAccess на странице сценарий развертывания щелкните развернуть DirectAccess только для удаленного управления, а затем нажмите кнопку Далее.In the DirectAccess Client Setup Wizard, on the Deployment Scenario page, click Deploy DirectAccess for remote management only, and then click Next.

3. На странице Выбор групп щелкните Добавить.On the Select Groups page, click Add.

4. В диалоговом окне Выбор групп выберите группы безопасности, содержащие клиентские компьютеры DirectAccess, а затем нажмите кнопку Далее.In the Select Groups dialog box, select the security groups that contain the DirectAccess client computers, and then click Next.

5. На странице Помощник по подключению к сети:On the Network Connectivity Assistant page:

   • В таблице добавьте ресурсы, которые будут использоваться для определения подключения к внутренней сети.In the table, add the resources that will be used to determine connectivity to the internal network. Если другие ресурсы не настроены, веб-проба по умолчанию создается автоматически.A default web probe is created automatically if no other resources are configured. При настройке расположения веб-проб для определения подключения к корпоративной сети убедитесь, что настроена хотя бы одна проверка на основе HTTP.When configuring the web probe locations for determining connectivity to the enterprise network, ensure that you have at least one HTTP based probe configured. Настройка только проверки связи не является достаточной и может привести к неправильному определению состояния подключения.Configuring only a ping probe is not sufficient, and it could lead to an inaccurate determination of connectivity status. Это вызвано тем, что проверка связи исключена из IPsec.This is because ping is exempted from IPsec. В результате проверка связи не гарантирует правильность установки туннелей IPsec.As a result, ping does not ensure that the IPsec tunnels are properly established.

   • Добавьте адрес электронной почты службы поддержки, чтобы позволить пользователям отправлять информацию при возникновении проблем с подключением.Add a Help Desk email address to allow users to send information if they experience connectivity issues.

   • Введите понятное имя для подключения DirectAccess.Provide a friendly name for the DirectAccess connection.

   • При необходимости установите флажок Разрешить клиентам DirectAccess использовать локальное разрешение имен.Select the Allow DirectAccess clients to use local name resolution check box, if required.

     Примечание

     Если разрешение локального имени включено, пользователи, выполняющие NCA, могут разрешать имена с помощью DNS-серверов, настроенных на клиентском компьютере DirectAccess.When local name resolution is enabled, users who are running the NCA can resolve names by using DNS servers that are configured on the DirectAccess client computer.

6. Нажмите кнопку Готово.Click Finish.

Настройка сервера удаленного доступаConfigure the Remote Access server

Чтобы развернуть удаленный доступ, необходимо настроить сервер, который будет использоваться в качестве сервера удаленного доступа, следующим образом:To deploy Remote Access, you need to configure the server that will act as the Remote Access server with the following:

1. Исправление сетевых адаптеровCorrect network adapters

2. Общедоступный URL-адрес сервера удаленного доступа, к которому могут подключаться клиентские компьютеры (адрес ssASnoversion)A public URL for the Remote Access server to which client computers can connect (the ConnectTo address)

3. Сертификат IP-HTTPS с субъектом, совпадающим с адресом ssASnoversion.An IP-HTTPS certificate with a subject that matches the ConnectTo address

4. Параметры IPv6IPv6 settings

5. Проверка подлинности клиентского компьютераClient computer authentication

Настройка сервера удаленного доступаTo configure the Remote Access server

1. В средней области консоли управления удаленным доступом в разделе Этап 2. Сервер удаленного доступа щелкните Настроить.In the middle pane of the Remote Access Management console, in the Step 2 Remote Access Server area, click Configure.

2. На странице Топология сети мастера настройки сервера удаленного доступа выберите топологию, которая будет использоваться в вашей организации.In the Remote Access Server Setup Wizard, on the Network Topology page, click the deployment topology that will be used in your organization. В поле Введите общедоступное имя или IPv4-адрес, используемые клиентами для подключения к серверу удаленного доступа введите общедоступное имя развертывания (оно совпадает с именем субъекта сертификата IP-HTTPS, например edge1.contoso.com), а затем нажмите кнопку Далее.In Type the public name or IPv4 address used by clients to connect to the Remote Access server, enter the public name for the deployment (this name matches the subject name of the IP-HTTPS certificate, for example, edge1.contoso.com), and then click Next.

3. На странице Сетевые адаптеры мастер автоматически обнаруживает:On the Network Adapters page, the wizard automatically detects:

   • Сетевые адаптеры для сетей в развертывании.Network adapters for the networks in your deployment. Если мастер не определяет правильные сетевые адаптеры, вручную выберите нужные адаптеры.If the wizard does not detect the correct network adapters, manually select the correct adapters.

   • Сертификат IP-HTTPS.IP-HTTPS certificate. Это основано на общедоступном имени развертывания, которое задается на предыдущем шаге мастера.This is based on the public name for the deployment that you set during the previous step of the wizard. Если мастер не обнаруживает правильный сертификат IP-HTTPS, нажмите кнопку Обзор , чтобы вручную выбрать правильный сертификат.If the wizard does not detect the correct IP-HTTPS certificate, click Browse to manually select the correct certificate.

4. Щелкните Далее.Click Next.

5. На странице Конфигурация префикса (Эта страница отображается только при обнаружении IPv6 во внутренней сети) мастер автоматически обнаруживает параметры IPv6, используемые во внутренней сети.On the Prefix Configuration page (this page is only visible if IPv6 is detected in the internal network), the wizard automatically detects the IPv6 settings that are used on the internal network. Если для развертывания требуются дополнительные префиксы, настройте префиксы IPv6 для внутренней сети, префикс IPv6, который будет назначен клиентским компьютерам DirectAccess, и префикс IPv6, который будет назначен клиентским компьютерам VPN.If your deployment requires additional prefixes, configure the IPv6 prefixes for the internal network, an IPv6 prefix to assign to DirectAccess client computers, and an IPv6 prefix to assign to VPN client computers.

6. На странице Проверка подлинности выполните следующие действия.On the Authentication page:

   • Для развертываний с несколькими сайтами и двухфакторной проверкой подлинности необходимо использовать проверку подлинности с сертификатом компьютера.For multisite and two-factor authentication deployments, you must use computer certificate authentication. Установите флажок использовать сертификаты компьютеров , чтобы использовать проверку подлинности сертификата компьютера, и выберите корневой сертификат IPSec.Select the Use computer certificates check box to use computer certificate authentication and select the IPsec root certificate.

   • Чтобы включить клиентские компьютеры под управлением Windows 7 для подключения через DirectAccess, установите флажок разрешить клиентским компьютерам Windows 7 подключаться с помощью DirectAccess .To enable client computers running Windows 7 to connect via DirectAccess, select the Enable Windows 7 client computers to connect via DirectAccess check box. В этом типе развертывания также следует использовать проверку подлинности с сертификатом компьютера.You must also use computer certificate authentication in this type of deployment.

7. Нажмите кнопку Готово.Click Finish.

Настройка серверов инфраструктурыConfigure the infrastructure servers

Чтобы настроить серверы инфраструктуры в развертывании с удаленным доступом, необходимо настроить следующие параметры.To configure the infrastructure servers in a Remote Access deployment, you must configure the following:

• Сервер сетевого размещенияNetwork location server

• Параметры DNS, включая список поиска DNS-суффиксовDNS settings, including the DNS suffix search list

• Любые серверы управления, которые не обнаруживаются службой удаленного доступа автоматическиAny management servers that are not automatically detected by Remote Access

Настройка серверов инфраструктурыTo configure the infrastructure servers

1. В средней области консоли управления удаленным доступом в разделе Этап 3. Серверы инфраструктуры щелкните Настроить.In the middle pane of the Remote Access Management console, in the Step 3 Infrastructure Servers area, click Configure.

2. На странице Сервер сетевых расположений мастера настройки серверов инфраструктуры щелкните параметр, соответствующий расположению сервера сетевых расположений в вашем развертывании.In the Infrastructure Server Setup Wizard, on the Network Location Server page, click the option that corresponds to the location of the network location server in your deployment.

   • Если сервер сетевого расположения находится на удаленном веб-сервере, введите URL-адрес и нажмите кнопку проверить , прежде чем продолжить.If the network location server is on a remote web server, enter the URL, and then click Validate before you continue.

   • Если сервер сетевых расположений размещен на сервере удаленного доступа, нажмите кнопку Обзор, чтобы найти соответствующий сертификат, а затем нажмите Далее.If the network location server is on the Remote Access server, click Browse to locate the relevant certificate, and then click Next.

3. На странице DNS в таблице введите дополнительные суффиксы имен, которые будут применяться как исключения таблица политики разрешения имен (NRPT).On the DNS page, in the table, enter additional name suffixes that will be applied as Name Resolution Policy Table (NRPT) exemptions. Выберите параметр локального разрешения имен и нажмите кнопку Далее.Select a local name resolution option, and then click Next.

4. На странице списка поиска DNS-суффиксов сервер удаленного доступа автоматически обнаруживает суффиксы домена в развертывании.On the DNS Suffix Search List page, the Remote Access server automatically detects domain suffixes in the deployment. Используйте кнопки Добавить и Удалить , чтобы создать список суффиксов домена, которые необходимо использовать.Use the Add and Remove buttons to create the list of domain suffixes that you want to use. Чтобы добавить новый суффикс домена, в поле Новый суффикс введите суффикс и нажмите кнопку Добавить.To add a new domain suffix, in New Suffix, enter the suffix, and then click Add. Щелкните Далее.Click Next.

5. На странице Управление добавьте серверы управления, которые не обнаруживаются автоматически, а затем нажмите кнопку Далее.On the Management page, add management servers that are not detected automatically, and then click Next. Удаленный доступ автоматически добавляет контроллеры домена и Configuration Manager серверы.Remote Access automatically adds domain controllers and Configuration Manager servers.

6. Нажмите кнопку Готово.Click Finish.

Настройка серверов приложенийConfigure application servers

При полном развертывании удаленного доступа Настройка серверов приложений является необязательной задачей.In a full Remote Access deployment, configuring application servers is an optional task. В этом сценарии для удаленного управления клиентами DirectAccess серверы приложений не используются, и этот шаг неактивен, чтобы указать, что он не активен.In this scenario for remote management of DirectAccess clients, application servers are not utilized and this step is greyed out to indicate that it is not active. Нажмите кнопку Готово , чтобы применить конфигурацию.Click Finish to apply the configuration.

Сводка конфигурации и альтернативные объекты групповой политикиConfiguration summary and alternate GPOs

После завершения настройки удаленного доступа отображается окно Сведения об удаленном доступе.When the Remote Access configuration is complete, the Remote Access Review is displayed. Вы можете просмотреть все параметры, выбранные ранее, в том числе следующие.You can review all of the settings that you previously selected, including:

• Параметры объекта групповой политикиGPO Settings

  Отобразится имя объекта групповой политики сервера DirectAccess и имя объекта групповой политики клиента.The DirectAccess server GPO name and Client GPO name are listed. Чтобы изменить параметры объекта групповой политики, щелкните ссылку изменить рядом с заголовком Параметры объекта групповой политики .You can click the Change link next to the GPO Settings heading to modify the GPO settings.

• Удаленные клиентыRemote Clients

  Отобразится Конфигурация клиента DirectAccess, включая группу безопасности, средства подключения и имя подключения DirectAccess.The DirectAccess client configuration is displayed, including the security group, connectivity verifiers, and DirectAccess connection name.

• Сервер удаленного доступаRemote Access Server

  Отобразится конфигурация DirectAccess, в том числе общедоступное имя и адрес, конфигурация сетевого адаптера и сведения о сертификате.The DirectAccess configuration is displayed, including the public name and address, network adapter configuration, and certificate information.

• Серверы инфраструктурыInfrastructure Servers

  этот список содержит URL-адрес сервера сетевых расположений, DNS-суффиксы, используемые клиентами DirectAccess, и сведения о серверах управления.This list includes the network location server URL, DNS suffixes that are used by DirectAccess clients, and management server information.

См. такжеSee also

Пошаговая инструкция по установке локальной версии – Enterprise

11. Установка программы на рабочие компьютеры

Загрузите инсталлятор программы (setup-local.exe) из Личного кабинета, вкладка «Инсталляция».

Загрузка программы и установочный код

В ходе установки программы потребуется указать тип инсталляции – выделенный сервер (Dedicated Server), IP адрес сервера и установочный код.

Выбор типа установки

Ввести параметры сервера: IP и ключ доступа

Указание необходимых параметров программы

Проверить указанные параметры сети: соединение с локальным сервером

Проверка связи с сервером

Проверить введенный ключ.

Проверка ключа установки

Завершение установки программы.

Завершение установки программы

После установки программы в систему автоматически добавиться наблюдаемый компьютер сотрудника. Список всех компьютером, где была установлена программа вы увидите в Настройках – Вкладка «Сотрудники».

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

Таким же образом выполните установку на другие компьютеры сотрудников.

В бесплатной пробной версии вы сможете 14 дней контролировать работу 25 сотрудников в локальной сети без каких либо ограничений. Попробуйте как это работает, тестируйте!

Настройка сервера

— последняя версия руководства администратора Nextcloud последняя версия

Использование cron для выполнения фоновых заданий

См. Описание фоновых заданий и
преимущества.

Снижение нагрузки на систему

Высокая загрузка системы замедлит работу Nextcloud, а также может привести к другим нежелательным
побочные эффекты. Чтобы снизить нагрузку, вы должны сначала определить источник проблемы.
Такие инструменты, как htop, iotop, netdata или
взгляды
поможет определить процесс или диск, замедляющий работу вашей системы.Первый
вы должны убедиться, что вы установили / назначили достаточно оперативной памяти. Использование свопа должно быть
предотвратить во что бы то ни стало. Если вы запускаете свою базу данных внутри виртуальной машины, вам не следует
сохраните его в файле образа виртуальной машины. Лучше поместите его на выделенное блочное устройство, чтобы
уменьшить задержку за счет нескольких уровней абстракции.

Кэширование

Caching повышает производительность за счет сохранения данных, кода и других объектов в памяти.
Конфигурация кеш-памяти для сервера Nextcloud должна быть установлена ​​и настроена.
См. Кэширование памяти.

Использование MariaDB / MySQL вместо SQLite

MySQL или MariaDB предпочтительнее из-за ограничений производительности
SQLite с приложениями с высокой степенью параллелизма, такими как Nextcloud.

См. Раздел Конфигурация базы данных, чтобы узнать, как
настроить Nextcloud для MySQL или MariaDB. Если ваша установка уже запущена на
SQLite, затем можно преобразовать в MySQL или MariaDB, используя предоставленные шаги
в Преобразование типа базы данных.

В небольших установках вы можете не захотеть настраивать отдельный кеш.Однако
вы все еще можете настроить свою базу данных. Следующий пример подходит для базы данных
меньше 1 ГБ. MySQL потребляет до 1 ГБ оперативной памяти для кеширования. Пожалуйста сделайте
убедитесь, что в вашей системе достаточно свободной оперативной памяти после изменения, чтобы она
не начинать использовать свой раздел подкачки, когда он получает пачку запросов. В
в данном примере ваш /etc/mysql/conf.d/mysql.cnf может содержать
следующие строки. (учтите, что это блок для mysqld, а не для mysql)

 [mysqld]
innodb_buffer_pool_size = 1 ГБ
innodb_io_capacity = 4000
 

Использование транзакционной блокировки файлов на основе Redis

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

Приложение для SSL / шифрования

SSL (HTTPS) и шифрование / дешифрование файлов могут быть загружены на процессор
Расширение AES-NI. Это может ускорить эти операции при понижении
накладные расходы на обработку. Для этого требуется процессор с набором инструкций AES-NI.

Вот несколько примеров, как проверить, поддерживает ли ваш ЦП / среда
Расширение AES-NI:

• Для каждого ядра ЦП: grep flags / proc / cpuinfo или как сводка для
  все ядра: grep -m 1 ^ flags / proc / cpuinfo Если результат содержит какие-либо
  aes , расширение присутствует.
• Поиск например. в сети Intel, если используемый процессор поддерживает расширение
  Фильтр функций процессора Intel Вы можете установить фильтр
  «Новые инструкции AES» для получения сокращенного набора результатов.
• Для версий openssl> = 1.0.1 AES-NI не работает через движок и
  не будет отображаться в команде openssl engine . По умолчанию активен
  на поддерживаемом оборудовании. Вы можете проверить версию openssl через openssl
версия -a
• Если ваш процессор поддерживает AES-NI, но он не отображается, например, с помощью grep или
  coreinfo, возможно, он отключен в BIOS.
• Если ваша среда работает виртуализированной, узнайте у поставщика виртуализации
  поддержка.

Настройка PHP-FPM

Если вы используете установку php-fpm по умолчанию, вы могли заметить
чрезмерное время загрузки веб-интерфейса или даже проблемы с синхронизацией. Это до
к тому, что каждый одновременный запрос элемента обрабатывается
отдельный процесс PHP-FPM. Так что даже при небольшой установке вы должны разрешить
больше процессов для запуска. Например, на машине с 4 ГБ ОЗУ и 1 ГБ
MySQL кеширует следующие значения в вашем www.conf должен работать:

 pm = динамический
pm.max_children = 120
pm.start_servers = 12
pm.min_spare_servers = 6
pm.max_spare_servers = 18
 

В зависимости от вашей текущей версии PHP вы должны найти этот файл, например под /etc/php/7.2/fpm/pool.d/www.conf

Включить PHP OPcache

OPcache повышает производительность приложений PHP за счет кэширования предварительно скомпилированного байт-кода. Мы рекомендуем как минимум следующие настройки:

 opcache.enable = 1
opcache.interned_strings_buffer = 8
opcache.max_accelerated_files = 10000
opcache.memory_consuming = 128
opcache.save_comments = 1
opcache.revalidate_freq = 1
 

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

.Конфигурация и настройка службы сервера

— Windows Server

• 21.09.2020
• 2 минуты на чтение

В этой статье

В этой статье описывается, как настроить и настроить службу Windows Server.

Версия данной статьи для Microsoft Windows XP: 314498.

Исходная версия продукта: Windows Server 2012 R2
Оригинальный номер базы знаний: 128167

Сводка

Хотя служба Windows Server является самонастраивающейся, ее также можно настроить вручную через службу панели управления. Обычно параметры конфигурации сервера автоматически настраиваются (рассчитываются и устанавливаются) при каждой загрузке Windows. Однако, если вы запускаете NET CONFIG SERVER вместе с переключателями / AUTODISCONNECT, / SERVCOMMENT OR / HIDDEN, текущие значения автоматически настроенных параметров отображаются и записываются в реестр.После того, как эти параметры записаны в реестр, вы не сможете настроить службу сервера с помощью сети панели управления.

Если вы добавляете или удаляете системную память или изменяете настройку размера сервера (минимизировать / сбалансировать / развернуть), Windows не будет автоматически настраивать службу сервера для вашей новой конфигурации. Например, если вы запустите NET CONFIG SRV / SRVCOMMENT, а затем увеличите объем памяти на компьютере, Windows не увеличит вычисленное значение автоматически настроенных записей.

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

Дополнительная информация

Серверная служба поддерживает информационные уровни, которые позволяют настраивать каждый параметр индивидуально. Например, команда NET CONFIG SRV / HIDDEN использует информационный уровень 1016 для установки только скрытого параметра. Однако NET.EXE запрашивает и устанавливает информационные уровни 102 (скрытые, комментарии, пользователи и параметры диска) и 502. В результате все параметры на информационном уровне постоянно устанавливаются в реестре. SRVMGR.EXE и сервер панели управления запрашивают и устанавливают только уровень 102 (не уровень 502) при изменении комментария сервера.

Администраторы, желающие скрыть компьютеры Windows из списка просмотра или изменить значение автоматического отключения, должны внести эти конкретные изменения с помощью REGEDT32.EXE вместо описанных выше эквивалентов командной строки. Комментарий сервера можно редактировать с помощью поля описания апплета сервера панели управления или диспетчера сервера.

Разрешение

Важно

Этот раздел, метод или задача содержат шаги, которые говорят вам, как изменить реестр. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы.Поэтому убедитесь, что вы выполните следующие действия внимательно. Для дополнительной защиты создайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Для получения дополнительных сведений о том, как создать резервную копию и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Microsoft:
322756 Как создать резервную копию и восстановить реестр в Windows

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

1. Запустите редактор реестра (REGEDT32.ИСПОЛНЯЕМЫЙ ФАЙЛ).

2. В поддереве HKEY_LOCAL_MACHINE перейдите к следующему ключу:

   \ SYSTEM \ CurrentControlSet \ Services \ LanmanServer \ Parameters

3. Удалить все записи, кроме следующих:
   EnableSharedNetDrives
   Lmannounce
   NullSessionPipes
   NullSessionShares
   Размер

   Примечание

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

4. Закройте редактор реестра и перезапустите Windows.

.

Настройка IIS 10.0 | Документы Microsoft

• 16.10.2017
• 23 минуты на чтение

В этой статье

Internet Information Services (IIS) 10.0 входит в состав Windows Server 2016. Он использует модель процесса, аналогичную модели IIS 8.5 и IIS 7.0. Веб-драйвер режима ядра (http.sys) получает и направляет HTTP-запросы и удовлетворяет запросы из своего кэша ответов.Рабочие процессы регистрируются для подпространств URL, а http.sys направляет запрос в соответствующий процесс (или набор процессов для пулов приложений).

HTTP.sys отвечает за управление подключением и обработку запросов. Запрос может обслуживаться из кеша HTTP.sys или передаваться рабочему процессу для дальнейшей обработки. Можно настроить несколько рабочих процессов, что обеспечивает изоляцию с меньшими затратами. Для получения дополнительной информации о том, как работает обработка запросов, см. Следующий рисунок:

HTTP.sys включает кеш ответов. Когда запрос соответствует записи в кэше ответов, HTTP.sys отправляет ответ кеша непосредственно из режима ядра. Некоторые платформы веб-приложений, такие как ASP.NET, предоставляют механизмы, позволяющие кэшировать любое динамическое содержимое в кэше режима ядра. Обработчик статических файлов в IIS 10.0 автоматически кэширует часто запрашиваемые файлы в http.sys.

Поскольку веб-сервер имеет компоненты режима ядра и пользовательского режима, оба компонента должны быть настроены для обеспечения оптимальной производительности.Таким образом, настройка IIS 10.0 для конкретной рабочей нагрузки включает настройку следующего:

• HTTP.sys и связанный с ним кеш режима ядра

• Рабочие процессы и IIS пользовательского режима, включая конфигурацию пула приложений

• Некоторые параметры настройки, влияющие на производительность

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

Настройки режима ядра

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

  HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters
  

Примечание
Если служба HTTP уже запущена, необходимо перезапустить ее, чтобы изменения вступили в силу.

Настройки управления кешем

Одно из преимуществ HTTP.sys — это кэш режима ядра.Если ответ находится в кэше режима ядра, вы можете полностью удовлетворить HTTP-запрос из режима ядра, что значительно снижает затраты ЦП на обработку запроса. Однако кэш режима ядра IIS 10.0 основан на физической памяти, а стоимость записи — это память, которую она занимает.

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

Ниже приведены некоторые полезные настройки для кеша режима ядра HTTP.sys:

• UriEnableCache Значение по умолчанию: 1

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

• UriMaxCacheMegabyteCount Значение по умолчанию: 0

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

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

  Â

• UriMaxUriBytes Значение по умолчанию: 262144 байта (256 КБ)

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

• UriScavengerPeriod Значение по умолчанию: 120 секунд

  Кэш HTTP.sys периодически проверяется сборщиком мусора, и записи, к которым нет доступа в период между сканированиями сборщика, удаляются. Установка высокого значения периода очистки снижает количество сканирований.Однако использование кэш-памяти может увеличиться, поскольку в кэше могут оставаться более старые, менее часто используемые записи. Установка слишком низкого периода вызывает более частое сканирование мусорщика и может привести к слишком большому количеству сбросов и оттоку кеша.

Настройки управления запросами и подключениями

В Windows Server 2016 HTTP.sys управляет подключениями автоматически. Следующие параметры реестра больше не используются:

• MaxConnections

    HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters \ MaxConnections
    

• IdleConnections HighMark

    HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters \ IdleConnectionsHighMark
    

• IdleConnectionsLowMark

    HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters \ IdleConnectionsLowMark
    

• IdleListTrimmerPeriod

    HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters \ IdleListTrimmerPeriod
    

• RequestBufferLookasideDepth

    HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters \ RequestBufferLookasideDepth
    

• InternalRequestLookasideDepth

    HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ Http \ Parameters \ InternalRequestLookasideDepth
    

Настройки пользовательского режима

Настройки в этом разделе влияют на IISÂ 10.0 поведение рабочего процесса. Большинство этих параметров можно найти в следующем файле конфигурации XML:

% SystemRoot% \ system32 \ inetsrv \ config \ applicationHost.config

Используйте Appcmd.exe, консоль управления IIS 10.0, командлеты PowerShell WebAdministration или IISAdministration, чтобы изменить их. Большинство настроек определяется автоматически, и они не требуют перезапуска рабочих процессов IIS 10.0 или сервера веб-приложений. Дополнительные сведения о файле applicationHost.config см. В разделе Введение в ApplicationHost.config.

Идеальная настройка ЦП для оборудования NUMA

Начиная с Windows 2016, IIS 10.0 поддерживает автоматическое назначение идеального ЦП для потоков пула потоков, чтобы повысить производительность и масштабируемость оборудования NUMA. Эта функция включена по умолчанию и может быть настроена с помощью следующего раздела реестра:

  HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Services \ InetInfo \ Parameters \ ThreadPoolUseIdealCpu
  

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

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

Настройки поведения кэша пользовательского режима

В этом разделе описаны параметры, влияющие на поведение кэширования в IISÂ 10.0. Кэш пользовательского режима реализован в виде модуля, который прослушивает события глобального кэширования, которые инициируются интегрированным конвейером. Чтобы полностью отключить кеш пользовательского режима, удалите модуль FileCacheModule (cachfile.dll) из списка установленных модулей в разделе конфигурации system.webServer / globalModules в applicationHost.config.

system.webServer / кеширование

Настройки режима сжатия

IIS, начиная с версии 7.0, по умолчанию сжимает статическое содержимое. Кроме того, сжатие динамического содержимого включено по умолчанию, если установлен DynamicCompressionModule. Сжатие снижает использование полосы пропускания, но увеличивает загрузку ЦП. Сжатый контент, если это возможно, кэшируется в кэше режима ядра. Начиная с версии 8.5, IIS позволяет управлять сжатием независимо для статического и динамического содержимого. Статическое содержимое обычно относится к содержимому, которое не изменяется, например файлам GIF или HTM.Динамическое содержимое обычно создается сценариями или кодом на сервере, то есть страницами ASP.NET. Вы можете настроить классификацию любого конкретного расширения как статического или динамического.

Чтобы полностью отключить сжатие, удалите StaticCompressionModule и DynamicCompressionModule из списка модулей в разделе system.webServer / globalModules в applicationHost.config.

system.webServer / httpCompression

system.webServer / urlCompression

Примечание

Для серверов под управлением IIS 10.0, которые имеют низкую среднюю загрузку ЦП, рассмотрите возможность включения сжатия для динамического содержимого, особенно если ответы большие. Сначала это следует сделать в тестовой среде, чтобы оценить влияние на использование ЦП по сравнению с базовым уровнем.

Настройка списка документов по умолчанию

Модуль документа по умолчанию обрабатывает HTTP-запросы для корня каталога и преобразует их в запросы для определенного файла, например Default.htm или Index.htm. В среднем около 25% всех запросов в Интернете проходят через путь к документу по умолчанию. Это значительно различается для отдельных сайтов. Когда в HTTP-запросе не указано имя файла, модуль документа по умолчанию выполняет поиск в списке разрешенных документов по умолчанию для каждого имени в файловой системе. Это может отрицательно сказаться на производительности, особенно если для доступа к содержимому необходимо выполнить круговой обход сети или прикоснуться к диску.

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

Вы можете выборочно установить поведение документа по умолчанию для определенных URL-адресов, настроив конфигурацию внутри тега местоположения в applicationHost.config или вставив файл web.config непосредственно в каталог содержимого. Это позволяет использовать гибридный подход, который позволяет использовать документы по умолчанию только там, где они необходимы, и устанавливает в списке правильное имя файла для каждого URL-адреса.

Чтобы полностью отключить документы по умолчанию, удалите DefaultDocumentModule из списка модулей в разделе system.webServer / globalModules в applicationHost.config.

system.webServer / defaultDocument

Центральный двоичный журнал

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

Вы можете включить центральное двоичное ведение журнала, установив для атрибута centralLogFileMode значение CentralBinary и установив для атрибута enabled значение True . Подумайте о том, чтобы переместить центральный файл журнала из системного раздела на специальный диск для ведения журнала, чтобы избежать конфликта между действиями системы и действиями по ведению журнала.

system.applicationHost / log

system.applicationHost / log / centralBinaryLogFile

Применение и настройка на месте

Следующие настройки относятся к настройкам пула приложений и сайта.

system.applicationHost / applicationPools / applicationPoolDefaults

system.applicationHost / sites / VirtualDirectoryDefault

Управление IIS 10.0 модулей

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

Веб-сервер, настроенный для простых статических файлов, может включать только следующие пять модулей: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule и HttpLoggingModule.

Чтобы удалить модули из applicationHost.config, удалите все ссылки на модуль из разделов system.webServer / handlers и system.webServer / modules в дополнение к удалению объявления модуля в system.webServer / globalModules.

Классические настройки ASP

Основные затраты на обработку классического запроса ASP включают инициализацию обработчика сценариев, компиляцию запрошенного сценария ASP в шаблон ASP и выполнение этого шаблона на обработчике сценариев. Хотя стоимость выполнения шаблона зависит от сложности запрошенного сценария ASP, классический модуль ASP IIS может кэшировать обработчики сценариев в памяти и шаблоны кеша как в памяти, так и на диске (только при переполнении кэша шаблонов в памяти) для повышения производительности в привязке к ЦП. сценарии.

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

system.webServer / asp / cache

система.webServer / asp / limits

система.webServer / asp / comPlus

Настройка параллелизма ASP.NET

ASP.NET 3.5

По умолчанию ASP.NET ограничивает параллелизм запросов, чтобы снизить постоянное потребление памяти на сервере. Приложениям с высоким уровнем параллелизма может потребоваться изменить некоторые параметры для повышения общей производительности. Вы можете изменить этот параметр в файле aspnet.config:

Следующий параметр полезен для полного использования ресурсов в системе:

• maxConcurrentRequestPerCpu Значение по умолчанию: 5000

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

ASP.NET 4,6

Помимо параметра maxConcurrentRequestPerCpu, ASP.NET 4.7 также предоставляет настройки для повышения производительности в приложениях, которые сильно зависят от асинхронной работы. Этот параметр можно изменить в файле aspnet.config.

• процентовCpuLimit Значение по умолчанию: 90
  Асинхронный запрос имеет некоторые проблемы с масштабируемостью, когда на такой сценарий ложится огромная нагрузка (за пределами возможностей оборудования).Проблема связана с характером распределения в асинхронных сценариях. В этих условиях распределение будет происходить при запуске асинхронной операции и будет использовано при ее завершении. К тому времени вполне возможно, что объекты были перемещены сборщиком мусора в поколение 1 или 2. Когда это произойдет, увеличение нагрузки покажет увеличение количества запросов в секунду (об / с) до определенного момента. Как только мы пройдем эту точку, время, проведенное в сборке мусора, станет проблемой, и частота вращения в секунду начнет падать, что окажет отрицательное влияние на масштабирование.Чтобы решить эту проблему, когда использование ЦП превышает значение параметра percentCpuLimit, запросы будут отправляться в собственную очередь ASP.NET.
• percentCpuLimitMinActiveRequestPerCpu Значение по умолчанию: 100
  Дросселирование ЦП (параметр percentCpuLimit) зависит не от количества запросов, а от их стоимости. В результате может быть всего несколько запросов с интенсивным использованием ЦП, вызывающих резервное копирование в собственной очереди без возможности очистить ее, кроме входящих запросов. Чтобы решить эту проблему, можно использовать процентCpuLimitMinActiveRequestPerCpu, чтобы гарантировать, что минимальное количество запросов обслуживается до того, как сработает дросселирование.

Рабочий процесс и варианты утилизации

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

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

system.applicationHost / applicationPools / ApplicationPoolDefaults / повторное использование / периодический перезапуск

Настройка динамического вывода страниц рабочего процесса

Начиная с Windows Server 2012 R2, IIS предлагает возможность настроить рабочий процесс для приостановки после того, как они некоторое время бездействовали (в дополнение к опции завершения, которая существовала с IIS 7).

Основная цель функций вывода страниц незанятого рабочего процесса и завершения простаивающего рабочего процесса состоит в сохранении использования памяти на сервере, поскольку сайт может потреблять много памяти, даже если он просто сидит и слушает. В зависимости от технологии, используемой на сайте (статический контент по сравнению с ASP.NET по сравнению с другими фреймворками), используемая память может составлять от 10 до сотен МБ, а это означает, что если на вашем сервере настроено много сайтов, выясняя наиболее эффективные настройки для ваших сайтов могут значительно повысить производительность как активных, так и заблокированных сайтов.

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

Примечание

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

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

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

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

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

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

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

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

Чтобы настроить заранее фиксированный размер файла подкачки, вам необходимо рассчитать его идеальный размер, который зависит от того, сколько сайтов вы будете приостанавливать и сколько памяти они потребляют.Если средний размер активного рабочего процесса составляет 200 МБ, и у вас есть 500 сайтов на серверах, которые будут приостановлены, тогда файл подкачки должен быть как минимум (200 * 500) МБ больше базового размера файла подкачки (так что base + 100 ГБ в нашем примере).

Примечание

Когда сайты приостановлены, они будут занимать примерно 6 МБ каждый, поэтому в нашем случае использование памяти, если все сайты приостановлены, будет около 3 ГБ. В действительности, однако, вы, вероятно, никогда не отстраните их всех одновременно.

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

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

• Включить поддержку активности HTTP для сеансов TLS. Это исключает затраты на установление сеанса.

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

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

Примечание

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

Интерфейс прикладного программирования Интернет-сервера (ISAPI)

Для приложений ISAPI не требуются специальные параметры настройки.Если вы пишете частное расширение ISAPI, убедитесь, что оно написано для повышения производительности и использования ресурсов.

Руководство по настройке управляемого кода

Интегрированная модель конвейера в IIS 10.0 обеспечивает высокую степень гибкости и расширяемости. Пользовательские модули, реализованные в собственном или управляемом коде, могут быть вставлены в конвейер или могут заменить существующие модули. Хотя эта модель расширяемости предлагает удобство и простоту, вы должны быть осторожны, прежде чем вставлять новые управляемые модули, которые подключаются к глобальным событиям.Добавление глобального управляемого модуля означает, что все запросы, включая запросы статических файлов, должны касаться управляемого кода. Пользовательские модули чувствительны к таким событиям, как сборка мусора. Кроме того, пользовательские модули значительно увеличивают затраты на ЦП из-за маршалинга данных между собственным и управляемым кодом. Если возможно, вы должны установить preCondition в managedHandler для управляемого модуля.

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

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

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

Правильное использование кэша вывода также повысит производительность вашего веб-сайта.

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

Другие проблемы, влияющие на производительность IIS

На производительность IIS могут влиять следующие проблемы:

• Установка фильтров, не поддерживающих кеширование

  Установка фильтра, не поддерживающего HTTP-кэш, приводит к тому, что IIS полностью отключает кеширование, что приводит к снижению производительности. Фильтры ISAPI, написанные до IISÂ 6.0, могут вызывать такое поведение.

• Запросы общего интерфейса шлюза (CGI)

  По соображениям производительности использование приложений CGI для обслуживания запросов с IIS не рекомендуется. Частое создание и удаление процессов CGI связано со значительными накладными расходами. Лучшие альтернативы включают использование сценариев FastCGI, приложений ISAPI и сценариев ASP или ASP.NET. Изоляция доступна для каждого из этих вариантов.

Дополнительные ссылки

.

веб-серверов для настройки производительности | Документы Microsoft

• 16.10.2017
• 2 минуты на чтение

В этой статье

В этом разделе описаны методы настройки производительности и рекомендации для веб-серверов Windows Server 2016.

Выбор подходящего оборудования для работы

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

Performance Tuning for Server Hardware содержит рекомендации по оборудованию, позволяющие избежать следующих ограничений производительности:

• Медленные ЦП предлагают ограниченную вычислительную мощность для рабочих нагрузок с интенсивным использованием ЦП, таких как сценарии ASP, ASP.NET и TLS.

• Небольшой кэш процессора L2 или L3 / LLC может отрицательно сказаться на производительности.

• Ограниченный объем памяти влияет на количество сайтов, которые могут быть размещены, количество сценариев динамического содержимого (например, ASP.NET) может храниться и количество пулов приложений или рабочих процессов.

• Сеть становится узким местом из-за неэффективного сетевого адаптера.

• Файловая система становится узким местом из-за неэффективной дисковой подсистемы или адаптера хранилища.

Оптимальные методы работы с операционной системой

Если возможно, начните с чистой установки операционной системы. При обновлении программного обеспечения могут остаться устаревшие, нежелательные или неоптимальные параметры реестра, а также ранее установленные службы и приложения, которые потребляют ресурсы, если они запускаются автоматически.Если установлена ​​другая операционная система, и вы должны ее сохранить, вам следует установить новую операционную систему в другой раздел. В противном случае новая установка перезапишет настройки в% Program Files% \ Common Files.

Чтобы уменьшить помехи при доступе к диску, поместите файл системной страницы, операционную систему, веб-данные, кэш шаблонов ASP и журнал служб IIS на отдельные физические диски, если это возможно.

Чтобы уменьшить конкуренцию за системные ресурсы, по возможности установите Microsoft SQL Server и IIS на разные серверы.

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

Настройки файловой системы NTFS

Глобальный системный переключатель NtfsDisableLastAccessUpdate (REG_DWORD) 1 находится в HKLM \ System \ CurrentControlSet \ Control \ FileSystem и по умолчанию установлен на 1. Этот переключатель снижает нагрузку на дисковый ввод-вывод и задержки, отключая дату и время. обновление штампа для последнего доступа к файлу или каталогу.Чистые установки Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 и Windows Server 2008 включают этот параметр по умолчанию, и вам не нужно его настраивать. В более ранних версиях Windows этот ключ не задавался. Если на вашем сервере установлена ​​более ранняя версия Windows или он был обновлен до Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 или Windows Server 2008, вам следует включить этот параметр.

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

Предупреждение

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

Дополнительные ссылки

.