Где находится сервер сайта: Как узнать, где расположен хостинг сайта?

Содержание

Хостинг сайта [узнать на каком сервере расположен сайт]

Время от времени вам могут попадаться какие-то интересные вам веб-сайты. Например, это может быть сайт вашего нового конкурента или просто какой-то веб-портал с превосходной (или плохой) скоростью загрузки. Вас может заинтересовать: «Что это за хост?».

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

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

Особенности бесплатной проверки веб-хостинга

Итак, как узнать, кто размещает веб-сайт? Введите его URL и нажмите «Проверить». Через несколько секунд вы получите отчет, содержащий следующую информацию:

У кого размещен этот сайт: сведения о веб-хостинге

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

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

Серверы имен являются фундаментальной частью DNS (системы доменных имен). Они обрабатывают запросы о местонахождении служб доменного имени. Серверы имен позволяют использовать домены вместо IP-адресов.

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

Где размещен сайт: сведения о сервере

В первой части отчета указано, на каком хосте расположен сайт. Вторая вкладка отвечает на вопрос «Где расположен хост сайта?». Тут вы найдете его IP-адрес, расположение сервера сайта (страна, город и регион) и название организации, которая им управляет.

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

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

Разница между хостингом веб-сайтов и реестром доменных имен

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

Реестр доменных имен – это база данных со всеми доменными именами и со связанной с ними информацией. Зачем вообще нужны доменные имена? У каждого веб-сайта есть свой уникальный идентификатор, называемый IP-адресом. Эту длинную цепочку чисел запомнить непросто. С IP-адресом связано уникальное доменное имя. Оно служит для человека удобным ярлыком, который пользователь в состоянии легко запомнить и назвать. Доменное имя – это то, что люди используют, чтобы найти ваш сайт. Если вы ищете доменные имена для своего бизнеса, вы можете использовать нашу Проверку доступности доменов.

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

Оценка хостинга

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

Время безотказной работы

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

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

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

Скорость загрузки

Медленный веб-сайт почти так же бесполезен, как и неработающий. Веб-сайт созданный для электронной коммерции и зарабатывающий 100 000 долларов в день, будет терять 2,5 миллиона долларов каждый год из-за задержки загрузки в 1 секунду. Поисковый рейтинг при этом также страдает. Независимо от того, какого провайдера вы выберете, необходима хорошая скорость загрузки сайта.

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

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

Служба поддержки

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

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

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

Цена

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

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

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

Как выбрать лучший хостинг для своего сайта

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

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

Чтобы облегчить вам выбор, мы провели обширное исследование. Вот статьи, которые могут вам помочь:

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

Ivan Palii

Marketing expert

Ivan works as a product marketing specialist at Sitechecker. Obsessed with analytics and creating a business strategy for SaaS products.

Что такое физический сервер и для чего он нужен? — Полезные статьи — Помощь

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

Физический сервер – это аппаратный комплекс, настроенный на хранение данных или непрерывное решение определенных задач.

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

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

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


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

Если Вы не имеете опыта в управлении физическим сервером, Вы всегда можете обратиться к нашим специалистам, которые помогут Вам выбрать базовую конфигурацию, отвечающую требованиям Вашего проекта. Также Вы можете воспользоваться услугой «Профессиональное администрирование», с которой управление арендованным сервером будет выглядеть для Вас также просто, как управление виртуальным хостингом. Специалисты .masterhost не только возьмут на себя все технические аспекты в виде установки и настройки программного комплекса, но и обеспечат Вам техническую поддержку в режиме 24/7.

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

В .masterhost Вы легко можете подобрать оптимальную конфигурацию физического сервера для аренды и использовать ресурсы современного оборудования в надежном дата-центре:

Выбрать сервер

Django Руководство часть 11: Разворачивание сайта на сервере — Изучение веб-разработки

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

Даже когда разработка вашего сайта завершена (или «достаточно» завершена для начала публичного тестирования), то для публичного доступа вам надо его где-то разместить.

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

  • Сделать несколько изменений в настройках проекта.
  • Выбрать/Настроить окружение для хостинга приложения Django.
  • Выбрать/Настроить окружение для размещения статических файлов.
  • В целях обслуживания сайта настроить инфраструктуру для его развёртывания.

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

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

  • Железо на котором будет запускаться сайт.
  • Операционную систему (Linux, Windows).
  • Языки программирования времени выполнения (скриптовые) и библиотеки, которые использует ваш сайт.
  • Веб-сервер, используемый для обслуживания страниц и другого контента (Nginx, Apache).
  • Сервер приложений, который передаёт «динамические» запросы между сайтом Django и веб-сервером.
  • Базу данных, от которой зависит ваш сайт.

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

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

Такой тип удалённого доступа к вычислительному/сетевому железу называется Инфраструктура как Сервис (Infrastructure as a Service — IaaS). Множество IaaS поставщиков предлагают услуги по предустановке какой-либо операционной системы, на которую вы можете установить необходимые для вашего рабочего окружения компоненты. Другие поставщики предлагают вам выбрать уже готовые полноценные рабочие окружения, возможно, включающие в себя Django и настроенный веб-сервер.

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

Некоторые провайдеры поддерживают Django как часть своего предложения Платформа как Сервис (Platform as a Service — PaaS). При данном виде хостинга вам не нужно беспокоиться о большей части окружения (веб-сервере, сервере приложений, балансировщике загрузки), так как сама платформа берёт это на себя (включая все моменты, касающиеся роста и развития вашего приложения). В данном случае развёртывание приложения является достаточно простой задачей, — вам нужно сконцентрироваться только на вашем приложении, а не на инфраструктуре.

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

Примечание: Если вы выбираете хостинг с поддержкой Python/Django, то он должен иметь инструкцию по установке веб-сайта Django, учитывающую различные конфигурации веб-сервера, сервера приложений, обратного прокси и так далее (это не имеет значение, если вы выбрали PaaS). Например, существует множество инструкций «шаг-за-шагом» для различный конфигураций в Документации DigitalOcean по Django.

Существует более 100 хорошо известных хостинг провайдеров, которые либо активно поддерживают, или работают с Django (их список можно увидеть в Django-дружественные хостинги). Данные поставщики предоставляют различные типы окружений (IaaS, PaaS), и различные уровни доступа к вычислительным и сетевым ресурсам, за разную цену.

Некоторые вещи на которые надо обратить внимание при выборе хостинга:

  • Насколько требовательным к вычислительным ресурсам является ваш сайт.
  • Уровень поддержки горизонтального (добавление большего количества машин) и вертикального масштабирования (переход на более мощное железо), а также стоимость всего этого.
  • Где расположены дата-центры и, следовательно, откуда будет более быстрый доступ.
  • Время непрерывной работы хостинга, а также время и количество простоя.
  • Инструменты, которые предоставляются для управления сайтом — простота и безопасность их использования (SFTP и FTP).
  • Встроенные фреймворки для мониторинга вашего сервера.
  • Ограничения. Некоторые хостинги могут блокировать некоторые сервисы (например, электронную почту) . Другие предлагают только определённое количество часов «живого времени» за определённую цену, или небольшое количество места для данных.
  • Преимущества. Некоторые провайдеры могут предложить бесплатные доменные имена и поддержку сертификатов SSL, которые, в других случаях, должны были бы купить.
  • Что будет при истечении времени использования «бесплатного» хостинга, какова «стоимость» миграции на более «дорогие» тарифы и так далее?

Хорошей новостью является то, что для того, чтобы начать существует достаточное количество компаний, которые предоставляют пробные «бесплатные» тарифы типа «evaluation» (для пробы), «developer» (разработка), или «hobbyist» (хобби). Всегда существуют ресурсы с ограниченным окружением, при использовании которых вам надо беспокоиться лишь о том, что они могут быть доступны лишь в течении определённого периода времени. Тем не менее, они являются отличным решением для тестирования сайтов с небольшим трафиком в реальном окружении, а также могут предоставлять простой доступ к платным ресурсам, в случае необходимости. Наиболее популярными провайдерами являются Heroku, Python Anywhere, Amazon Web Services, Microsoft Azure и так далее.

Многие провайдеры имеют «basic» (базовый) тариф, предоставляющий достаточный уровень вычислительной мощности с небольшим количеством ограничений. Digital Ocean и Python Anywhere являются примерами провайдеров, которые предлагают относительно недорогой базовый тариф (от $5 до $10USD в месяц).

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

Скелет сайта был создан при помощи инструментов django-admin и manage.py, которые настроены таким образом, чтобы сделать разработку проще. Многие настройки файла проекта (определённых в settings.py) должны быть изменены перед публикацией сайта, либо из-за вопросов безопасности, либо производительности.

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

Критически важные настройки файла settings.py:

Давайте изменим приложение LocalLibrary таким образом, чтобы читать SECRET_KEY и DEBUG из переменных окружения, если те определены, иначе использовать значения по умолчанию.

Откройте /locallibrary/settings.py, закомментируйте исходное значение SECRET_KEY и добавьте новые строки, как указано ниже жирным. В течении разработки, никаких переменных окружения определено не было, таким образом будут использоваться значения по умолчанию (не имеет значения какой ключ вы используете в процессе разработки, поскольку при развёртывании проекта вы будете использовать другой).



import os
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY', 'cg#p$g+j9tax!#[email protected]$8obt2_+&k3q+pmu)5%asj6yjpkag')

Затем закомментируйте строку с настройкой DEBUG, а затем, добавьте новую, указанную ниже.



DEBUG = bool( os.environ.get('DJANGO_DEBUG', True) )

Значение DEBUG будет True по умолчанию и станет False, в том случае, если переменная окружения DJANGO_DEBUG будет проинициализирована пустой строкой, то есть, DJANGO_DEBUG=''.

Примечание: Было бы более понятным, если бы мы могли просто установить и снять с  DJANGO_DEBUG непосредственно на True и False , напрямую, а не использовать «любую строку» или «пустую строку» (соответственно). К сожалению, значения переменных среды хранятся как строки Python и единственная строка, которая оценивается как False является пустой строкой (например, bool('')==False).

Весь перечень настроек для разворачивания вашего сайта находится по ссылке Deployment checklist (Django docs). Кроме того, вы можете получить список настроек, выполнив в терминале команду:

python3 manage.py check --deploy

Данный раздел предоставляет демонстрацию того, как установить LocalLibrary на Heroku PaaS cloud.

Почему Heroku?

Heroku — один из самых продолжительных и популярных облачных сервисов PaaS. Первоначально он поддерживал только приложения Ruby, но теперь его можно использовать для размещения приложений из многих сред программирования, включая Django!

Мы выбираем для использования Heroku по нескольким причинам:

  • У Heroku есть свободный уровень, который действительно свободен (хотя и с некоторыми ограничениями)
  • Как PaaS, Heroku заботится о большой веб-инфраструктуре для нас. Это значительно облегчает работу, потому что вы не беспокоитесь о серверах, балансирах нагрузки, обратных прокси или любой другой веб-инфраструктуре, которую Heroku предоставляет нам под капотом.
  • Хотя у этого есть некоторые ограничения, это не повлияет на это конкретное приложение. Например:
    • Heroku предоставляет только недолговечное хранилище, поэтому загруженные пользователем файлы нельзя безопасно хранить на самом Heroku.
    • Свободный уровень будет спать с неактивным веб-приложением, если в течение получаса не будет запросов. После этого сайт может занять несколько секунд, чтобы ответить, когда он проснулся.
    • Свободный уровень ограничивает время, в течение которого ваш сайт работает до определённого количества часов каждый месяц (не включая время, когда сайт «спит»). Это нормально для сайта с низким уровнем использования / демонстрации, но не подходит, если требуется 100% время безотказной работы.
    • Другие ограничения перечислены в Limits (документы Heroku).
  • В основном это просто работает, и если вы в конечном итоге полюбите его, масштабирование вашего приложения будет очень простым.

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

Как работает Heroku?

Heroku запускает сайты Django внутри одного, или более,  изолированных друг от друга «Dynos», которые являются виртуальными Unix-контейнерами, предоставляющими необходимое окружение для вашего приложения. Данные dynos полностью изолированы и имеют эфемерную файловую систему («короткоживущая» файловая система, которая полностью очищается и обновляется каждый раз, когда dyno перезапускается). Единственной сущностью, которую предоставляет dynos по умолчанию, является приложение по конфигурации переменных. Heroku внутри себя применяет балансировщик загрузки для распределения веб-трафика среди всех «веб»-dynos. Поскольку dynos изолированы, Heroku может масштабировать приложение горизонтально, просто добавляя больше dynos (хотя, конечно, у вас может появиться необходимость расширить базу данных для обработки дополнительных соединений).

Файловая система эфемерна, поэтому вы не можете напрямую установить необходимые для вашего приложения сервисы (то есть, базы данных, очереди, системы кеширования, хранения, сервисы электронной почты и так далее). Взамен этого, Heroku предоставляет сервисы, доступные как независимые «дополнения» («add-ons») либо от самой Heroku, или от сторонних разработчиков. В тот момент когда ваше приложение запускается в системе, dynos получает доступ к сервисам, используя информацию, содержащуюся в переменных настройки вашего приложения.

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

  • runtime.txt: язык программирования и его версию.
  • requirements.txt: необходимые для Python компоненты, включая Django.
  • Procfile: Список процессов, которые будут выполнены для старта веб-приложения. Для Django это обычно сервер веб-приложений Gunicorn (скрипт .wsgi).
  • wsgi.py: конфигурация WSGI для вызова нашего приложения Django в окружении Heroku.

Разработчики Developers взаимодействуют с Heroku при помощи специального клиентского приложения/терминала, который сильно похож на bash-скрипт Unix. Оно позволяет вам загружать код, находящийся в git-репозитории, контроллировать выполняемые процессы, смотреть логи, устанавливать конфигурационные переменные и многое другое!

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

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

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

На этом завершается краткий обзор начала работы с Heroku (более подробное руководство Как работает Heroku).

Создание репозитория приложения на Github

Heroku тесно интегрирована с системой управления версиями исходного кода git, используя её для загрузки / синхронизации любых изменений, которые вы вносите в живую систему. Он делает это, добавляя новый «удалённый» репозиторий heroku с именем heroku, указывающий на репозиторий для вашего источника в облаке Heroku. Во время разработки вы используете git для хранения изменений в вашем «master» репозитории. Когда вы хотите развернуть свой сайт, вы синхронизируете свои изменения в репозитории Heroku.

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

Существует множество способов работы с git, но одним из самых простых является создание учётной записи в Github, создание репозитория там, а затем синхронизация с ним локально:

  1. Посетите https://github.com/ и создайте аккаунт.
  2. После входа в систему нажмите ссылку + в верхней панели инструментов и выберите Новый репозиторий.
  3. Заполните все поля на этой форме. Хотя они не являются обязательными, они настоятельно рекомендуются.
  4. Нажмите кнопку Create repository, тем самым создав ваш репозиторий.
  5. Перейдите на страницу вашего репозитория. Там нажмите на зелёную кнопку «Clone or download«. Скопируйте URL  из текстового поля из появившегося диалогового окна (Это будет похоже на: https://github. com/<your_git_user_id>/django_local_library.git). Здесь <your_git_user_id> — это будет ваш id пользователя git.

Когда ваш репозиторий будет создан — загрузите его себе на компьютер, следуя инструкции, описанной ниже:

  1. Установите git себе на компьютер (Вы можете найти версию для своей платформы здесь).
  2. Откройте командную строку (или терминал) и выполните в нём следующую команду, используя ссылку, которую вы получили с github:
    git clone https://github.com/<your_git_user_id>/django_local_library.git
    
    Это создаст подпапку (с содержанием вашего репозитория и именем вашего репозитория) внутри папки, в которой выполнялась команда.
  3. Перейдите в эту папку:
    cd django_local_library.git

Последний шаг. Нужно скопировать ваше Django-приложение и добавить его файлы в новый репозиторий, используя git:

  1. Скопируйте ваше приложение в папку репозитория (все файлы с таким же уровнем, как у manage. py, БЕЗ папки проекта, в которой эти файлы находятся).
  2. Откройте файл с расширением .gitignore в текстовом редакторе, вставьте в самый его конец строки, приведённые ниже, а затем сохраните (этот файл «говорит» о файлах, которые не должны быть  загружены в git по умолчанию).
    # Text backup files
    *.bak
    
    #Database
    *.sqlite3
  3. Откройте командную строку или терминал и используйте add команду с флагом -A. Эта команда сохранит изменения в репозиторий:

    git add -A
  4. Используйте команду status,  что бы убедиться, что все файлы, которые вы собираетесь добавить верны (вы хотите включить исходные файлы, а не бинарные файлы, временные файлы и т. д.). В консоль выведется что то вроде этого:
    > git status
    On branch master
    Your branch is up-to-date with 'origin/master'.
    Changes to be committed:
      (use "git reset HEAD <file>. .." to unstage)
    
            modified:   .gitignore
            new file:   catalog/__init__.py
            ...
            new file:   catalog/migrations/0001_initial.py
            ...
            new file:   templates/registration/password_reset_form.html
  5. Теперь, зафиксируйте файлы в локальном репозитории:
    git commit -m "First version of application moved into github"
  6. Синхронизируете свой локальный репозиторий с сайтом Github:
    git push origin master

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

Подсказка: Это хороший момент для создания резервной копии вашего «ванильного» проекта — в то время как некоторые изменения, которые мы собираемся сделать в следующих разделах, могут быть полезны для развёртывания на любой платформе (или разработке), которые другие могут не использовать.

Лучший способ сделать это — использовать git для управления вашими изменениями. С git вы можете не только вернуться к определённой старой версии, но и сохранить её в отдельной «ветке» ваших производственных изменений, and cherry-pick — выбрать любые изменения для перемещения между ветвями производства и развития. Изучение Git будет стоить усилий, но это выходит за рамки данной темы. Самый простой способ сделать это — просто скопировать файлы в другое место. Используйте тот подход, который наилучшим образом соответствует вашим знаниям git!

Обновить приложение для Heroku 

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

Procfile

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

web: gunicorn locallibrary.wsgi --log-file -

«web:» сообщает Heroku, что это веб динамический и может быть отправлен HTTP-трафик. Процесс, который начнётся в этом динамически, — это gunicorn, который является популярным сервером веб-приложений, который рекомендует Heroku. Мы запускаем Gunicorn, используя конфигурационную информацию в модуле locallibrary.wsgi (созданный с помощью нашего скелета приложения: /locallibrary/wsgi.py).

Gunicorn

Gunicorn рекомендуемый http сервер с Django на Heroku (Как указано в Procfile выше). Это чистый python http сервер для WSGI приложений  которые могут запускать множество параллельных python процессов в пределах одного динамического (посмотрите Deploying Python applications with Gunicorn для получения большей информации).

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

Установка Gunicorn локально в командной строке используя пакетный менеджер pip (которые мы установили когда настраивали среду разработки):

pip3 install gunicorn
Настройка Базы Данных

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

Механизм Heroku для обработки этой ситуации заключается в использовании надстройки базы данных и настройке веб-приложения с использованием информации из переменной конфигурации среды, установленной надстройкой. Существует множество опций базы данных, но мы будем использовать hobby уровень в базе данных postgres Heroku, поскольку это бесплатно, поддерживается Django и автоматически добавляется в наши новые приложения Heroku при использовании бесплатного уровня динамического плана для хобби.

Информация о подключении базы данных предоставляется на web dyno, используя конфигурационную переменную с именем DATABASE_URL. Вместо того, чтобы жёстко кодировать эту информацию в Django, Heroku рекомендует разработчикам использовать dj-database-url пакет для анализа DATABASE_URL переменную окружения и автоматически преобразовать её в желаемый формат конфигурации Django. В дополнение к установке пакета dj-database-url нам также потребуется установить psycopg2, поскольку Django нуждается в этом, чтобы взаимодействовать с базами данных Postgres.

dj-database-url (Django конфигурации базы данных из переменной окружения)

Установите dj-database-url локально, чтобы он стал частью наших требований к настройке Heroku на удалённом сервере:

$ pip3 install dj-database-url
settings.py

Откройте /locallibrary/settings.py и скопируйте следующую конфигурацию в нижнюю часть файла:

# Heroku: Update database configuration from $DATABASE_URL. 
import dj_database_url
db_from_env = dj_database_url.config(conn_max_age=500)
DATABASES['default'].update(db_from_env)

Примечание:

  • Мы все ещё будем использовать SQLite во время разработки, поскольку DATABASE_URL переменная среды не будет установлена ​​на нашем компьютере разработки.
  • Значение conn_max_age=500 делает соединение постоянным, что намного эффективнее, чем воссоздавать соединение в каждом цикле запросов. Однако это необязательно и при необходимости можно удалить.
psycopg2 (Python Postgres database support)

Django нуждается в psycopg2 для работы с базами данных Postgres, и вам нужно будет добавить это в файл требований.txt для Heroku, чтобы установить это на удалённом сервере (как описано в разделе требований ниже).

Django будет использовать нашу базу данных SQLite локально по умолчанию, поскольку переменная среды DATABASE_URL не задана в нашей локальной среде. Если вы хотите полностью перейти на Postgres и использовать нашу бесплатную базу данных Heroku для разработки и производства, то вы можете. Например, чтобы установить psycopg2 и его зависимости локально в системе на базе Linux, вы должны использовать следующие команды bash / terminal:

sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib
pip3 install psycopg2

Инструкции по установке для других платформ можно найти на веб-сайте psycopg2.

Однако вам не нужно это делать — вам не нужно, чтобы PostGreSQL был активным на локальном компьютере, если вы передаёте его в Heroku в качестве требования в файле требований.txt (см. Ниже).

Обслуживание статических файлов в производстве


Во время разработки мы использовали Django и веб-сервер разработки Django для обслуживания наших статических файлов (CSS, JavaScript и т. Д.). В производственной среде вместо этого мы обычно обслуживаем статические файлы из сети доставки контента (CDN) или веб-сервера.

Примечание. Обслуживание статических файлов через Django / веб-приложение неэффективно, потому что запросы должны проходить через ненужный дополнительный код (Django), а не обрабатываться непосредственно веб-сервером или полностью отдельным CDN. Хотя это не имеет значения для местного использования во время разработки, это будет иметь значительное влияние на производительность, если мы будем использовать тот же подход в производстве.

Чтобы упростить размещение статических файлов отдельно от веб-приложения Django, Django предоставляет средство сбора данных для сбора этих файлов для развёртывания (имеется переменная параметров, определяющая, где файлы должны собираться при запуске collectstatic). Шаблоны Django относятся к месту размещения статических файлов относительно переменной параметров (STATIC_URL), так что это можно изменить, если статические файлы перемещаются на другой хост / сервер.

Соответствующими параметрами настройки являются:

     STATIC_URL: это базовое расположение URL, из которого будут загружены статические файлы, например, на CDN. Это используется для переменной статического шаблона, доступ к которой осуществляется в нашем базовом шаблоне (см. Учебник по Django Part 5: Создание нашей домашней страницы).
      STATIC_ROOT: Это абсолютный путь к каталогу, в котором инструмент «collectstatic» Django будет собирать любые статические файлы, упомянутые в наших шаблонах. После их сбора они затем могут быть загружены в группу, где бы файлы не размещались.
      STATICFILES_DIRS: В этом списке перечислены дополнительные каталоги, в которых инструмент коллективного поиска Django должен искать статические файлы.

settings.py

Откройте /locallibrary/settings.py и скопируйте следующую конфигурацию в нижнюю часть файла. BASE_DIR уже должен быть определён в вашем файле (STATIC_URL, возможно, уже был определён в файле, когда он был создан. В то время как это не причинит вреда, вы также можете удалить дублируемую предыдущую ссылку).

# Static files (CSS, JavaScript, Images)
# https://docs.djangoproject.com/en/1.10/howto/static-files/

# The absolute path to the directory where collectstatic will collect static files for deployment.
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')

# The URL to use when referring to static files (where they will be served from)
STATIC_URL = '/static/'

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

Для получения дополнительной информации см. Django и Static Assets (документы Heroku).

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

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

Шаги по настройке WhiteNoise для использования в проекте:

WhiteNoise

Установите WhiteNoise локально, используя следующую команду:

$ pip3 install whitenoise
settings.py

Чтобы установить WhiteNoise в приложение Django, откройте /locallibrary/settings.py, найдите параметр MIDDLEWARE и добавьте WhiteNoiseMiddleware в верхней части списка, чуть ниже SecurityMiddleware:

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'whitenoise.middleware.WhiteNoiseMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

При желании вы можете уменьшить размер статических файлов при их обслуживании (это более эффективно). Просто добавьте следующее в конец /locallibrary/settings.py:

# Simplified static file serving.
# https://warehouse.python.org/project/whitenoise/
STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
Requirements

Требования Python вашего веб-приложения должны храниться в файле requirements.txt в корневом каталоге вашего репозитория. После этого Heroku автоматически установит их при восстановлении вашей среды. Вы можете создать этот файл с помощью pip в командной строке (запустите в корне repo):

pip3 freeze > requirements.txt

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

dj-database-url==0.4.1
Django==1.10.2
gunicorn==19.6.0
psycopg2==2.6.2
whitenoise==3.2.2

Убедитесь, что строка  psycopg2, подобная приведённой выше, присутствует! Даже если вы не установили это локально, вы должны добавить это в requirements.txt.

Среда выполнения

Файл runtime.txt, если определён, говорит Heroku, какой язык программирования использовать. Создайте файл в корне репо и добавьте следующий текст:

python-3.5.2

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

Сохраните изменения в Github и перепроверьте

Далее мы сохраним все наши изменения в Github. В терминале (whist внутри нашего репозитория) введите следующие команды:

git add -A
git commit -m "Added files and changes required for deployment to heroku"
git push origin master

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

python3 manage.py runserver

Теперь мы должны быть готовы начать развёртывание LocalLibrary на Heroku.

Получить аккаунт в heroku

Чтобы начать использовать Heroku, вам сначала нужно создать учётную запись:

  • Перейдите www.heroku.com и нажмите SIGN UP FOR FREE кнопку.
  • Введите ваши данные, а затем нажмите  CREATE FREE ACCOUNT. Вам будет предложено проверить свою учётную запись по адресу электронной почты для регистрации.
  • Нажмите ссылку активации учётной записи в электронной почте для регистрации. Вы вернётесь в свою учётную запись в веб-браузере.
  • Введите свой пароль и нажмите  SET PASSWORD AND LOGIN.
  • Затем вы войдёте в систему и попадёте в приборную панель Heroku: https://dashboard.heroku.com/apps.

Установка клиента

Загрузите и установите клиент Heroku, следуя инструкциям Heroku здесь.

После установки клиента вам будут доступны команды. Например, чтобы получить справку о клиенте:

heroku help

Создание и загрузка веб-сайта

Чтобы создать приложение, мы запускаем команду «create» в корневом каталоге нашего репозитория. Это создаёт git remote («указатель на удалённый репозиторий»), названный heroku в нашей локальной среде git.

heroku create

Примечание: вы можете назвать удалённый, если хотите, указав значение после «create». Если вы этого не сделаете, вы получите случайное имя. Имя используется в URL-адресе по умолчанию.

Затем мы можем подтолкнуть наше приложение в репозиторий heroku как показано ниже. Это позволит загрузить приложение, упаковать его в dyno, запустить collectstatic, и запустить сам сайт.

git push heroku master

Если нам повезёт, приложение «заработает» на сайте, но оно не будет работать должным образом, потому что мы не настроили таблицы базы данных для использования нашим приложением. Для этого нам нужно использовать команду  heroku run и запустить «one off dyno» для выполнения операции переноса. Введите в терминал следующую команду:

heroku run python manage.py migrate

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

heroku run python manage.py createsuperuser

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

heroku open

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

Управление аддонами

Вы можете проверить дополнения в своём приложении, используя heroku addons команду. Это будет список всех аддонов, их ценовая категория и состояние.

>heroku addons

Add-on                                     Plan       Price  State
─────────────────────────────────────────  ─────────  ─────  ───────
heroku-postgresql (postgresql-flat-26536)  hobby-dev  free   created
 └─ as DATABASE

Здесь мы видим, что у нас есть только одна надстройка, база данных postgres SQL. Это бесплатно и автоматически создаётся при создании приложения. Вы можете открыть веб-страницу, чтобы более подробно изучить надстройку базы данных (или любое другое дополнение), используя следующую команду:

heroku addons:open heroku-postgresql

Другие команды позволяют создавать, уничтожать, обновлять и понижать аддоны (используя аналогичный синтаксис для открытия). Для получения дополнительной информации см.  Managing Add-ons (Heroku docs).

Настройка переменных конфигурации

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

>heroku config

=== locallibrary Config Vars
DATABASE_URL: postgres://uzfnbcyxidzgrl:[email protected]s.com:5432/dbftm4qgh4kda3

Если вы вспомните из раздела, посвящённого  getting the website ready to publish, мы должны установить переменные среды для DJANGO_SECRET_KEY и DJANGO_DEBUG. Давайте сделаем это сейчас.

Примечание: Секретный ключ должен быть действительно секретным! Один из способов генерации нового ключа — создать новый проект Django (django-admin startproject someprojectname) а затем получить ключ, который генерируется для вас в его settings.py.

Мы устанавливаем  DJANGO_SECRET_KEY используя команду config:set (как показано ниже). Не забудьте использовать свой секретный ключ!

>heroku config:set DJANGO_SECRET_KEY=eu09([email protected][email protected]*$ehh9-)3u_83+y%(+phh&=

Setting DJANGO_SECRET_KEY and restarting locallibrary... done, v7
DJANGO_SECRET_KEY: eu09([email protected][email protected]*$ehh9-)3u_83+y%(+phh

Аналогично мы устанавливаем  DJANGO_DEBUG:

>heroku config:set DJANGO_DEBUG=''

Setting DJANGO_DEBUG and restarting locallibrary... done, v8

Если вы посетите веб-сайт сейчас, вы получите ошибку «Bad request» , потому что в  ALLOWED_HOSTS надо внести параметры, если у вас DEBUG=False (в качестве меры безопасности). Откройте /locallibrary/settings.py и измените ALLOWED_HOSTS для включения вашего базового URL-адреса приложения (например, ‘locallibrary1234.herokuapp.com’) URL, который вы обычно используете на локальном сервере разработки.

ALLOWED_HOSTS = ['<your app URL without the https:// prefix>.herokuapp.com','127.0.0.1']


Затем сохраните настройки и передайте их в репозиторий Github и в Heroku:

git add -A
git commit -m 'Update ALLOWED_HOSTS with site and development server URL'
git push origin master
git push heroku master

После завершения обновления сайта на Heroku введите URL-адрес, который не существует (например,  /catalog/doesnotexist/). Раньше это отображало бы подробную страницу отладки, но теперь вы должны просто увидеть простую страницу «Не найдено».

Отладка

Клиент Heroku предоставляет несколько инструментов для отладки:

heroku logs  
heroku logs --tail 
heroku config:set DEBUG_COLLECTSTATIC=1 
heroku ps   

Если вам нужно больше информации, предоставленной здесь, вам нужно будет начать изучать Django Logging.

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

Веб-хостинг – Amazon Web Services (AWS)

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

Простые веб-сайты обычно состоят из одного веб-сервера, на котором работает либо система управления контентом (CMS), например WordPress, либо приложение электронной коммерции, например Magento, либо стек разработки, например LAMP. Это программное обеспечение позволяет легко создавать, обновлять и обслуживать контент веб-сайта, а также управлять им.

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

Оптимальный вариант в следующих случаях

  • Веб-сайты на базе обычных приложений, таких как WordPress, Joomla, Drupal, Magento
  • Веб-сайты на основе популярных стеков разработки, таких как LAMP, LEMP, MEAN, Node.Js
  • Веб-сайты, которые едва ли будут масштабироваться более чем на 5 серверов
  • Клиенты, которые хотят управлять собственным веб-сервером и ресурсами
  • Клиенты, которые хотят управлять своим веб-сервером, DNS и сетью из одной консоли

Статические веб-сайты доставляют посетителям HTML-страницы, объекты JavaScript, изображения, видео и другие файлы, при этом не содержат прикладного кода, например PHP или ASP.NET. Обычно такие варианты используются для личных или маркетинговых сайтов.

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

Оптимальный вариант в следующих случаях:

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

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

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

Оптимальный вариант в следующих случаях:

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

cPanel: как узнать IP-адрес сервера, на котором размещен сайт

6719 Посещений

Нередко у пользователей возникает необходимость выяснить IP-адрес сервера, на котором размещен сайт. Сделать это можно в панели управления хостингом cPanel. Зайдите на главную страницу сервиса, где слева собрана ключевая информация. Нажмите на кнопку Expand Stats → “Сведения о сервере”, чтобы развернуть весь список и найдите параметр “Общий IP-адрес”:

Интеграция сайта ArcGIS Server с порталом—ArcGIS Server

При объединении сайта ArcGIS Server с порталом модели безопасности и общего доступа портала интегрируются с одним или несколькими сайтами ArcGIS Server. Интеграция не является обязательной, если только вам не требуется следующее:

  • Настроить сайт на работу с провайдером идентификации Security Assertion Markup Language (SAML).
  • Разместить слои листов, векторные слои и слои сцен, опубликованные участниками портала.
  • Разрешить участникам портала выполнять пространственный анализ в Map Viewer.

Когда вы объединяете сервер с порталом, как описано в этом разделе, вы интегрируете сервер с порталом. Сервер, объединённый с порталом, называется интегрированным сервером.

Элементы вашего основного развертывания ArcGIS Enterprise, включая размещенный сервер, должны иметь ту же версию, что и ваш портал. Все сайты ArcGIS GeoEvent Server и GeoAnalytics Server, а также сайты модуля анализа растров ArcGIS Image Server также должны быть версии, соответствующей версии портала.

Однако некоторые сайты ArcGIS Server версии 10.5 или более поздней версии могут быть интегрированы с порталом более новой версии. Это применимо к дополнительным сайтам ArcGIS GIS Server хост-сервера и ко всем ArcGIS Image Server, не предназначенным для анализа растров. Сайт ArcGIS Server не может быть интегрирован с порталом более ранней версии, чем он сам.

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

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

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

Прежние версии:

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

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

Если планируется использовать для работы с Portal for ArcGIS обратный прокси-сервер вашей организации, перед выполнением перечисленных ниже действий нужно добавить портал на обратный прокси. Подробные инструкции см. в разделе Использование обратного прокси-сервера с Portal for ArcGIS.

В следующих шагах показано, как интегрировать сайт ArcGIS Server с вашим порталом.

После интеграции сервера с порталом вам может потребоваться сделать следующее:

«Макхост» — платный хостинг для сайта

«Макхост» — это хостинг-провайдер, предоставляющий услуги хостинга с 2004 года. Нашим новым и постоянным клиентам доступны бонусы и акции: домен в подарок при оплате хостинга на год и больше, бесплатный месяц при переезде от другого хостера, скидки до 36% при оплате за длительный период. Подробные условия описаны на странице «Акции». Купить хостинг можно через биллинг-панель:

  1. Выберите подходящий тариф.
  2. Зарегистрируйтесь.
  3. Внесите оплату и дождитесь активации аккаунта.

Техническая поддержка работает круглосуточно без выходных и праздничных дней. Дата-центры находятся в России и Европе — DataPro (Москва), DataCenter (Амстердам) и Serverius (Меппел). Все оборудование принадлежит компании «Макхост».

Услуги «Макхост»

  1. Виртуальный хостинг (shared hosting). Когда множество веб-сайтов расположены на одном сервере.
  2. Виртуальные выделенные серверы (virtual private/dedicated server). VPS/VDS эмулирует работу отдельного физического сервера.
  3. Аренда выделенных серверов (dedicated server). Когда клиенту предоставляется отдельная физическая машина.
  1. CMS-хостинг. Специальные тарифы, оптимизированные под 1С-Битрикс, Joomla и WordPress.
  2. Премиум хостинг. С неограниченным трафиком и 100% нагрузкой на одно ядро процессора.
  3. Продажа SSL-сертификатов. Sectigo, Thawte, Let’s Encrypt.
  4. Регистрация доменов. Доступно более 50 доменных зон.

Цена услуг зависит от объема дискового пространства, допустимой пиковой нагрузки, количества сайтов, БД MySQL и других конфигураций.

Наши преимущества

Аптайм (время бесперебойной работы) «Макхост» составляет свыше 99,9%. Мы поддерживаем все популярные языки программирования и CMS. Нами разработана собственная удобная панель управления. На виртуальном и VPS хостинге мы используем скоростные SSD-диски фирмы «Dell». Поддержка работает 24/7 для решения ваших вопросов.

Обратный поиск изображений с помощью HostingChecker

Об инструменте поиска обратного изображения

Этот инструмент экономит время, когда вы выполняете обратный поиск изображений. Он создает ссылки на самые популярные поисковые системы обратного фото: Google, Bing, Yandex, Tineye, Baidu и Sogou .

Мы также поддерживаем специализированный поиск, например поисковые системы аниме и манги и KarmaDecay для Reddit .

Вы также можете найти изображения, похожие на то, которое вы ищете, на самых популярных сайтах бесплатных стоковых фотографий, таких как Pixabay, Unsplash, Pexels, Reshot, StockSnap, ISORepublic, Burst, FreeStocks.org, Flickr и PicJumbo , которые индексируются Google.

Условия использования

Вы не можете загружать нелегальные изображения на сервер. Мы регистрируем IP-адреса и сообщаем властям о любых нарушениях.

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

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

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

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

Поддерживаемые типы файлов: jpg, jpeg, png, gif, и размер файла должен быть от до 5 МБ .

Мы используем Google Captcha V3 для защиты от спама. Вы можете ознакомиться с Условиями и Политикой Google здесь.

Как использовать обратный поиск изображений

Вы можете вставить URL-адрес изображения или фотографии из Интернета или загрузить его на наш сервер со своего компьютера.

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

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

Вы также можете сделать это с помощью поиска похожих фотографий.

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

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

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

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

Вы также можете использовать изображения из памяти телефона или вставить URL-адрес изображения, которое вы хотите найти.

Мы протестировали поиск по фото на разных телефонах Android, iPhone, iPad, телефонах Windows и разных планшетах.

Кому может быть полезен обратный поиск фотографий?

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

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

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

Обычные пользователи Интернета могут использовать обратный поиск фотографий для:

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

Использование обратного поиска изображений

Защищайте авторские права и избегайте плагиата

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

Найдите источник изображения или фотографии

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

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

Найдите поддельные профили и аккаунты в социальных сетях

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

Найти визуально похожие изображения

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

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

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

Найти продукты и места

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

Обратный поиск gif

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

Многие большие платформы gif переходят на формат webp. Он еще не поддерживается крупными компаниями по поиску фотографий (даже Google, который настаивает на этом), и поэтому мы еще не поддерживаем этот формат «gif». Мы обновим метапоиск, как только формат webp gif получит широкую поддержку.

Планирование ролей системы сайта — Configuration Manager

  • Читать 9 минут

В этой статье

Применимо к: Configuration Manager (текущая ветвь)

Каждый устанавливаемый сайт Configuration Manager включает в себя сервер сайта, который является сервером системы сайта . Сайт также может включать дополнительные серверы системы сайта на компьютерах, удаленных от сервера сайта.Серверы системы сайта (сервер сайта или удаленный сервер системы сайта) поддерживают роли системы сайта .

Серверы системы сайта

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

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

Роли системы сайта

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

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

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

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

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

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

Сервер сайта Configuration Manager

Эта роль определяет сервер, на котором выполняется установка Configuration Manager для установки сайта, или сервер, на котором вы устанавливаете вторичный сайт. Вы не можете переместить или удалить эту роль, пока сайт не будет удален.

Система сайта Configuration Manager

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

Компонент Configuration Manager роль системы сайта

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

Сервер базы данных сайта Configuration Manager

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

Провайдер SMS

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

Чтобы установить дополнительных поставщиков, запустите программу установки Configuration Manager для управления поставщиком SMS. Затем установите дополнительных провайдеров на дополнительные компьютеры. Установите на компьютер только один экземпляр поставщика SMS. Этот компьютер должен находиться в том же домене, что и сервер сайта.

Точка синхронизации аналитики активов

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

Дополнительные сведения см. В разделе Аналитика активов в Configuration Manager.

Пункт регистрации сертификатов

Роль системы сайта, которая взаимодействует с сервером, на котором работает служба регистрации сетевых устройств (NDES).Эта роль управляет запросами сертификатов устройств, которые используют простой протокол регистрации сертификатов (SCEP). Эта роль поддерживается только на первичных сайтах и ​​на сайте центра администрирования.

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

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

Точка подключения шлюза управления облаком

Роль системы сайта для связи со шлюзом управления облаком.

Пункт обслуживания хранилища данных

Используйте точку обслуживания хранилища данных для хранения и составления отчетов о долгосрочных исторических данных в среде Configuration Manager.Для получения дополнительной информации см. Хранилище данных.

Пункт выдачи

Роль системы сайта, которая содержит исходные файлы для загрузки клиентами, например:

  • Содержание приложения
  • Программные пакеты
  • Обновления программного обеспечения
  • Образы ОС
  • Загрузочные образы

По умолчанию эта роль устанавливается на сервере сайта при установке нового первичного или вторичного сайта. Эта роль не поддерживается на сайте центра администрирования.Установите несколько экземпляров этой роли на поддерживаемом сайте и на нескольких сайтах в одной иерархии. Дополнительные сведения см. В разделах «Основные концепции управления содержимым» и «Управление содержимым и инфраструктурой содержимого».

Точка защиты конечной точки

Роль системы сайта, которую Configuration Manager использует для принятия условий лицензии Endpoint Protection и для настройки членства по умолчанию для Cloud Protection Service. Иерархия поддерживает только один экземпляр этой роли, и он должен находиться на сайте верхнего уровня.Если вы расширяете автономный первичный сайт в более крупную иерархию, удалите эту роль с первичного сайта, а затем установите ее на сайте центра администрирования. Дополнительные сведения см. В разделе Endpoint Protection в Configuration Manager.

Пункт зачисления

Роль системы сайта, которая использует сертификаты PKI для Configuration Manager для регистрации мобильных устройств и компьютеров MacOS. Хотя эта роль поддерживается только на первичных сайтах, вы можете установить несколько экземпляров этой роли на сайте или на нескольких сайтах в одной иерархии.

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

Прокси-точка регистрации

Роль системы сайта, которая управляет запросами на регистрацию Configuration Manager с мобильных устройств и компьютеров MacOS. Хотя эта роль поддерживается только на первичных сайтах, вы можете установить несколько экземпляров этой роли на сайте или на нескольких сайтах в одной иерархии.

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

Соединитель сервера Exchange

Дополнительные сведения об этой роли см. В разделе Управление мобильными устройствами с помощью Configuration Manager и Exchange.

Резервная точка состояния

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

Точка управления

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

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

Настройте точки управления для поддержки HTTP или HTTP. Они также могут поддерживать мобильные устройства, которыми вы управляете с помощью локального управления мобильными устройствами (MDM) Configuration Manager. Чтобы снизить нагрузку на сервер базы данных сайта, связанную с обслуживанием запросов от клиентов, используйте реплики базы данных для точек управления.

Важно

Начиная с версии 2103 Configuration Manager, сайты, разрешающие обмен данными с HTTP-клиентом, устарели. Настройте сайт для HTTPS или Enhanced HTTP. Дополнительные сведения см. В разделе Включение сайта только для HTTPS или расширенного HTTP.

Пункт предоставления отчетности

Роль системы сайта, которая интегрируется со службами отчетов SQL Server для создания отчетов для Configuration Manager и управления ими. Эта роль поддерживается на первичных сайтах и ​​сайте центра администрирования, и вы можете установить несколько экземпляров этой роли на поддерживаемом сайте.Для получения дополнительной информации см. Планирование отчетности.

Точка подключения сервисного обслуживания

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

Точка обновления программного обеспечения

Роль системы сайта, которая интегрируется со службами Windows Server Update Services (WSUS) для предоставления обновлений программного обеспечения клиентам Configuration Manager. Эта роль поддерживается на всех сайтах:

  • Установите эту систему сайта на сайте центра администрирования для синхронизации с WSUS.

  • Настройте каждый экземпляр этой роли на дочерних первичных сайтах для синхронизации с сайтом центра администрирования.

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

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

Государственная точка миграции

При переносе компьютера на новую операционную систему эта роль системы сайта хранит данные о состоянии пользователя. Эта роль поддерживается на первичных и вторичных сайтах. Установите несколько экземпляров этой роли на сайте и на нескольких сайтах в одной иерархии.Дополнительные сведения о сохранении состояния пользователя при развертывании ОС см. В разделе Управление состоянием пользователя.

Следующие шаги

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

memdocs / site-server-high-availability.md на главном сервере · MicrosoftDocs / memdocs · GitHub

заголовок названиеSuffix описание мс.дата мс производ мс по технологиям мс тема ms.assetid автор гс. Автор менеджер

Высокая доступность сервера сайта

Диспетчер конфигураций

Как настроить высокую доступность для сервера сайта Configuration Manager, добавив сервер сайта в пассивном режиме.

14.05.2021

менеджер конфигурации

configmgr-core

концептуальный

6dcef836-c0d1-40af-ad30-cd8d864b09a9

aczechowski

Ааронц

dougeby

Применимо к: Configuration Manager (текущая ветвь)

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

Эта функция дает следующие преимущества

  • Избыточность и высокая доступность для роли сервера сайта
  • Более простая замена оборудования или ОС сервера сайта
  • Более простой перенос сервера сайта на Azure IaaS

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

Сервер сайта в пассивном режиме:

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

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

Microsoft Core Services Engineering and Operations использовала эту функцию для миграции своего CAS в Microsoft Azure. Дополнительные сведения см. В статье Microsoft IT Showcase.

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

  • Configuration Manager поддерживает серверы сайта в пассивном режиме в иерархии.У CAS и дочерних первичных сайтов может быть другой сервер сайта в пассивном режиме.

  • Сервер сайта в пассивном режиме может быть локальным или облачным в Azure.

    [! ПРИМЕЧАНИЕ] Облачный сервер сайта в пассивном режиме использует инфраструктуру Azure как услугу (IaaS). Дополнительные сведения см. В следующих статьях:

Предварительные требования

Active Directory

  • Оба сервера сайта должны быть присоединены к одному домену Active Directory.

  • Если вы расширили схему Active Directory для Configuration Manager, обоим серверам сайта требуются разрешения Full Control для контейнера Active Directory System — System Management и всех дочерних объектов.

Общие конфигурации для обоих серверов сайта

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

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

Конфигурации для сервера сайта в пассивном режиме

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

    • Это требование включает такие компоненты, как .NET Framework, удаленное разностное сжатие и Windows ADK. Полный список см. В разделе Предварительные требования к сайту и системе сайта.

    [! ПРИМЕЧАНИЕ] Обязательно установите собственный клиент SQL Server. Если вы не установите его, средство проверки предварительных требований во время установки Configuration Manager сообщит об ошибке об отсутствии разрешений SQL Server.

  • Должен иметь учетную запись компьютера в локальной группе «Администраторы » на сервере сайта в активном режиме.

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

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

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

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

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

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

Библиотека содержимого

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

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

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

База данных сайта

Оба сервера сайта должны использовать одну и ту же базу данных сайта.

  • База данных может быть удалена с каждого сервера сайта. Процесс установки Configuration Manager не блокирует установку роли сервера сайта на компьютере с ролью Windows для отказоустойчивой кластеризации. Для групп доступности SQL Server AlwaysOn эта роль требуется, поэтому ранее вы не могли размещать базу данных сайта на сервере сайта.Благодаря этому изменению вы можете создать сайт с высокой доступностью с меньшим количеством серверов, используя группу доступности и сервер сайта в пассивном режиме.

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

  • Оба сервера сайта нуждаются в роли безопасности sysadmin на экземпляре SQL Server, на котором размещена база данных сайта. У исходного сервера сайта уже должны быть эти роли, поэтому добавьте их для нового сервера сайта.Например, следующий сценарий SQL добавляет эти роли для нового сервера сайта VM2 в домене Contoso:

     USE [master]
    ИДТИ
    СОЗДАТЬ ВХОД [contoso \ vm2 $] ИЗ WINDOWS С DEFAULT_DATABASE = [master], DEFAULT_LANGUAGE = [us_english]
    ИДТИ
    ИЗМЕНИТЬ РОЛЬ СЕРВЕРА [системный администратор] ДОБАВИТЬ УЧАСТНИКА [contoso \ vm2 $]
    GO 
  • Оба сервера сайта нуждаются в доступе к базе данных сайта на экземпляре SQL Server. У исходного сервера сайта уже должен быть этот доступ, поэтому добавьте его для нового сервера сайта.Например, следующий сценарий SQL добавляет имя входа в базу данных CM_ABC для нового сервера сайта VM2 в домене Contoso:

     ИСПОЛЬЗОВАТЬ [CM_ABC]
    ИДТИ
    СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ [contoso \ vm2 $] ДЛЯ ВХОДА [contoso \ vm2 $] С DEFAULT_SCHEMA = [dbo]
    GO 
  • Сервер сайта в пассивном режиме настроен на использование той же базы данных сайта, что и сервер сайта в активном режиме. Сервер сайта в пассивном режиме только читает из базы данных. Он не записывает данные в базу данных до тех пор, пока не будет переведен в активный режим.

Ограничения

  • На каждом сайте поддерживается только один сервер сайта в пассивном режиме.

  • Сервер сайта в пассивном режиме не поддерживается на дополнительном сайте.

    [! ПРИМЕЧАНИЕ] Вторичные сайты по-прежнему поддерживаются первичным сайтом с высокодоступными серверами сайтов.

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

  • Роли системы сайта нельзя установить на новый сервер до добавления сервера сайта в пассивном режиме.

    [! ПРИМЕЧАНИЕ] После установки сервера сайта в пассивном режиме вы можете при необходимости добавить дополнительные роли. Например, точка управления на первичном сайте.

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

  • Консоль Configuration Manager не устанавливается автоматически на сервере сайта в пассивном режиме.

Добавить сервер сайта в пассивном режиме

Дополнительные сведения об общем процессе добавления ролей см. В разделе Установка ролей системы сайта.

  1. В консоли Configuration Manager перейдите в рабочую область Administration , разверните Site Configuration , выберите узел Sites и выберите Create Site System Server на ленте.

  2. На странице Общие мастера создания сервера системы сайта укажите сервер, на котором будет размещен сервер сайта в пассивном режиме. Указанный вами сервер не может размещать какие-либо роли системы сайта до установки сервера сайта в пассивном режиме.

  3. На странице Выбор системной роли выберите только сервер сайта в пассивном режиме .

    [! ПРИМЕЧАНИЕ]
    Мастер выполняет следующие предварительные проверки на этой странице:

    • Выбранный сервер не является сервером вторичного сайта
    • Выбранный сервер еще не является сервером сайта в пассивном режиме
    • Библиотека содержимого сайта находится в удаленном месте

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

  4. На странице Сервер сайта в пассивном режиме укажите следующую информацию, которая используется для запуска установки и установки роли сервера сайта на указанном сервере:

    • Выберите один из следующих вариантов:

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

      • Используйте исходные файлы в следующем месте на сервере сайта в пассивном режиме : Например, локальный путь, по которому вы уже скопировали исходные файлы.Убедитесь, что это содержимое той же версии, что и сервер сайта в активном режиме.

      • ( рекомендуется ) Используйте исходные файлы в следующем сетевом расположении : укажите путь непосредственно к содержимому компакт-диска . Последняя папка с сервера сайта в активном режиме. Например, \\ Server \ SMS_ABC \ CD.Latest , где « Server » — это имя сервера сайта в активном режиме, а « ABC » — код сайта.

    • Укажите локальный путь для установки Configuration Manager на новом сервере сайта.Например: C: \ Program Files \ Configuration Manager

  5. Завершите работу мастера. Затем Configuration Manager устанавливает сервер сайта в пассивном режиме на указанном сервере.

Для получения подробных сведений о состоянии установки в консоли перейдите в рабочее пространство Monitoring и выберите узел Site Server Status . Состояние сервера сайта в пассивном режиме отображается как Установка . Для получения более подробной информации выберите сервер и выберите Показать статус .Это действие открывает окно «Состояние установки сервера сайта». Когда процесс завершен, состояние показывает OK для обоих серверов.

Для получения дополнительной информации о процессе установки см. Блок-схема — Настройка сервера сайта в пассивном режиме.

После добавления сервера сайта в пассивном режиме просмотрите оба сервера сайта на вкладке Nodes в узле Sites консоли.

Все компоненты сервера сайта Configuration Manager находятся в режиме ожидания на сервере сайта в пассивном режиме.Службы Windows все еще работают.

Раскрутка сервера сайта

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

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

  • Определите свои рабочие процессы во время переключения при отказе и способы взаимодействия с другими администраторами Configuration Manager.

  • Перед плановой рекламной кампанией:

    • Проверьте общее состояние сайта и его компонентов. Убедитесь, что все в норме для вашего окружения.

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

    • Проверьте состояние вторичного сайта и репликацию сайта.

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

      [! ПРИМЕЧАНИЕ] Если во время отработки отказа выполняется репликация файла или базы данных между сайтами, новый сервер сайта может не получить реплицированный контент. В этом случае распространите содержимое программного обеспечения после того, как новый сервер сайта станет активным. Для репликации базы данных может потребоваться повторная инициализация вторичного сайта после отработки отказа.

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

      [! СОВЕТ] Вот пример того, как другие действия могут конфликтовать с продвижением сервера сайта:

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

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

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

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

[! ВАЖНО]
Если все экземпляры поставщика SMS отключены, вы не можете подключиться к сайту, поскольку поставщик недоступен.При добавлении сервера сайта в пассивном режиме программа установки устанавливает на этом сервере экземпляр поставщика SMS.

Консоль Configuration Manager запрашивает список доступных поставщиков SMS у WMI на сервере сайта. Когда вы устанавливаете несколько поставщиков SMS на сайте, сайт случайным образом назначает каждый новый запрос на подключение для использования установленного поставщика SMS. Вы не можете указать расположение поставщика SMS для использования в конкретном сеансе подключения. Если ваша консоль не может подключиться к сайту из-за того, что текущий сервер сайта отключен, укажите другой сервер сайта в окне «Подключение к сайту».

  1. В консоли Configuration Manager перейдите в рабочую область Administration , разверните Site Configuration и выберите узел Sites . Выберите сайт, а затем перейдите на вкладку Nodes . Выберите сервер сайта в пассивном режиме, а затем выберите на ленте Сделать активным . Выберите Да для подтверждения и продолжения.

  2. Обновите узел консоли. Столбец Status для сервера, который вы продвигаете, отображается на вкладке Nodes как Promoting .

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

Для получения подробных сведений о состоянии перейдите в рабочее пространство Monitoring и выберите узел Site Server Status . Столбец Mode определяет, какой сервер является Активным или Пассивным .Когда вы переводите сервер из пассивного режима в активный, выберите сервер сайта, который вы переводите в активный, а затем выберите Показать статус на ленте. Это действие открывает окно «Состояние повышения статуса сервера сайта», в котором отображаются более подробные сведения о процессе.

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

Для получения дополнительной информации о процессе повышения , запланированном на , см. Блок-схема — Повышение уровня сервера сайта (запланировано).

Незапланированное переключение при отказе

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

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

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

Для получения дополнительной информации о незапланированном процессе отработки отказа см. Блок-схема — Повышение уровня сервера сайта (незапланированное).

Прочие задачи после раскрутки сервера сайта

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

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

Ежедневный мониторинг

Если у вас есть сервер сайта в пассивном режиме, отслеживайте его ежедневно. Убедитесь, что его статус остается в порядке и готов к использованию. В консоли Configuration Manager перейдите в рабочую область Monitoring и выберите узел Site Server Status . Просмотрите оба сервера сайта и их текущий статус.Также просмотрите статус в рабочем пространстве Администрирование . Разверните Site Configuration и выберите узел Sites . Выберите сайт, а затем перейдите на вкладку Nodes .

[! ПРИМЕЧАНИЕ] Когда вы обновляете сайт до новой версии Configuration Manager, он также обновляет сервер сайта в пассивном режиме.

Удалить сервер сайта в пассивном режиме

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

Когда вы удаляете любую другую роль системы сайта, менеджер компонентов сайта ( sitecomp ) обрабатывает запрос. Когда вы удаляете сервер сайта в пассивном режиме, диспетчер отработки отказа обрабатывает запрос. Для статуса отслеживайте компонент SMS_FAILOVER_MANAGER .

Следующие шаги

Блок-схема

— Настройка сервера сайта в пассивном режиме Блок-схема — продвижение сервера сайта (планируется) Блок-схема — продвижение сервера сайта (незапланировано)

файлов журнала SCCM | Файлы журнала ConfigMgr | Файлы журнала MEMCM

Этот пост действительно полезен для людей, которые ищут файлы журналов SCCM.Файлы журнала можно просмотреть с помощью инструмента CMTrace, расположенного по пути: <установочный DVD-диск SCCM> SMSSETUP / TOOLS .

Журналы клиента SCCM находятся по пути: % WINDIR% System32 / CCM / Logs. для 64-разрядной операционной системы: % WINDIR% SysWOW64CCMLogs. Файлы журнала сервера SCCM находятся в папке: Logs или SMS_CCMLogs.

Файлы журнала клиента SCCM

  • CAS — Служба доступа к контенту.Поддерживает локальный кеш пакетов.
  • Ccmexec.log — Записывает действия клиента и службы узла агента SMS.
  • CertificateMain maintenance.log — поддерживает сертификаты для службы каталогов Active Directory и точек управления.
  • ClientIDManagerStartup.log — создает и поддерживает идентификатор GUID клиента.
  • ClientLocation.log — Задачи назначения сайта.
  • ContentTransferManager.log — планирует фоновую интеллектуальную службу передачи (BITS) или блок сообщений сервера (SMB) для загрузки или доступа к пакетам SMS.
  • DataTransferService.log — записывает все сообщения BITS для доступа к политике или пакетам.
  • Execmgr.log — записывает запускаемые рекламные объявления.
  • FileBITS.log — записывает все задачи доступа к пакету SMB.
  • Fsinvprovider.log (переименованный в FileSystemFile.log во всех пакетах обновления для SMS 2003) — поставщик инструментария управления Windows (WMI) для инвентаризации программного обеспечения и сбора файлов.
  • InventoryAgent.log — создает записи данных обнаружения (DDR) и записи инвентаризации оборудования и программного обеспечения.
  • LocationServices.log — находит точки управления и распространения.
  • Mifprovider.log — поставщик WMI для файлов .MIF.
  • Mtrmgr.log — отслеживает все процессы измерения программного обеспечения.
  • PolicyAgent.log — запрашивает политики с помощью службы передачи данных.
  • PolicyAgentProvider.log — записывает изменения политики.
  • PolicyEvaluator.log — записывает новые параметры политики.
  • Remctrl.log — регистрирует запуск компонента удаленного управления (WUSER32).
  • Scheduler.log — Записывает задачи расписания для всех клиентских операций.
  • Smscliui.log — записывает использование инструмента управления системами на панели управления.
  • StatusAgent.log — регистрирует сообщения о состоянии, создаваемые клиентскими компонентами.
  • SWMTRReportGen.log — создает отчет с данными об использовании, который собирается агентом измерения. (Эти данные заносятся в журнал Mtrmgr.log.)

Файлы журнала сервера SCCM

  • Ccm.log — задачи Client Configuration Manager.
  • Cidm.log — Записывает изменения в настройках клиента с помощью диспетчера данных установки клиента (CIDM).
  • Colleval.log — Журналы, когда коллекции создаются, изменяются и удаляются оценщиком коллекций.
  • Compsumm.log — Записывает задачи сумматора состояния компонентов.
  • Cscnfsvc.log — Записывает задачи службы подтверждения отправителя курьера.
  • Dataldr.log — файлы формата информации управления процессами (MIF) и инвентаризация оборудования в базе данных Configuration Manager 2007.
  • Ddm.log — сохраняет информацию DDR в базе данных Configuration Manager 2007 с помощью Discovery Data Manager.
  • Despool.log — записывает входящие передачи данных между сайтами.
  • Distmgr.log — Записывает создание пакетов, сжатие, дельта-репликацию и обновления информации.
  • Hman.log — записывает изменения конфигурации сайта и публикует информацию о сайте в доменных службах Active Directory.
  • Inboxast.log — записывает файлы, перемещаемые из точки управления в соответствующую папку SMSINBOXES.
  • Inboxmgr.log — ведение файла записей.
  • Invproc.log — записывает обработку дельта-файлов MIF для компонента Dataloader из файлов инвентаризации клиента.
  • Mpcontrol.log — записывает регистрацию точки управления с помощью WINS. Регистрирует доступность точки управления каждые 10 минут.
  • Mpfdm.log — компонент точки управления, который перемещает клиентские файлы в соответствующую папку SMSINBOXES.
  • MPMSI.log — точка управления.Журнал установки msi.
  • MPSetup.log — записывает процесс установки оболочки точки управления.
  • Ntsvrdis.log — обнаружение сервера Configuration Manager 2007.
  • Offermgr.log — Записывает обновления рекламы.
  • Offersum.log — записывает сводку сообщений о состоянии рекламы.
  • Policypv.log — записывает обновления клиентских политик, чтобы отразить изменения в настройках клиента или рекламных объявлениях.
  • Replmgr.log — записывает репликацию файлов между компонентами сервера сайта и компонентом планировщика.
  • Rsetup.log — Журнал настройки точки отчетности.
  • Sched.log — записывает межсайтовые задания и репликацию пакетов.
  • Sender.log — записывает файлы, которые отправляются на другие дочерние и родительские сайты.
  • Sinvproc.log — записывает обработку данных инвентаризации клиентского программного обеспечения в базу данных сайта в Microsoft SQL Server.
  • Sitecomp.log — записывает обслуживание установленных компонентов сайта.
  • Sitectrl.log — записывает изменения настроек сайта в Sitectrl.ct0 файл.
  • Sitestat.log — записывает процесс мониторинга всех систем сайта.
  • Smsdbmon.log — записывает изменения базы данных.
  • Smsexec.log — Записывает обработку всех потоков компонентов сервера сайта.
  • Smsprov.log — Записывает доступ поставщика WMI к базе данных сайта.
  • SMSReportingInstall.log — записывает установку Reporting Point. Этот компонент запускает задачи установки и обрабатывает изменения конфигурации.
  • SMSSHVSetup.log — записывает успех или сбой (с указанием причины сбоя) установки точки проверки работоспособности системы.
  • Srvacct.log — записывает обслуживание учетных записей, когда сайт использует стандартную безопасность.
  • Statmgr.log — Записывает все сообщения о состоянии в базу данных.
  • Swmproc.log — обрабатывает файлы измерений и поддерживает настройки.

Файлы журнала установки сервера сайта

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

Имя файла журнала сервера сайта Описание Расположение файла журнала сервера сайта
ConfigMgrPrereq.журнал Записывает предварительную оценку компонентов и действия по установке Сервер сайта
ConfigMgrSetup.log Записывает подробные выходные данные настройки сервера сайта. Сервер сайта
ConfigMgrSetupWizard.log Записывает информацию, относящуюся к действиям мастера установки. Сервер сайта
SMS_BOOTSTRAP.log Записывает информацию о ходе запуска процесса установки вторичного сайта.Подробная информация о фактическом процессе установки содержится в ConfigMgrSetup.log. Сервер сайта
smstsvc.log Записывает информацию об установке, использовании и удалении службы Windows. Windows использует эту службу для проверки сетевого подключения и разрешений между серверами. Он использует компьютерную учетную запись сервера, который создает соединение. Сервер сайта и сервер системы сайта

Файлы журнала аналитики активов

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

Имя файла журнала аналитики активов Описание Расположение файла аналитики активов
AssetAdvisor.log Записывает действия инвентаризации аналитики активов. Клиентский компьютер
aikbmgr.log Записывает сведения об обработке файлов XML из папки «Входящие» для обновления каталога аналитики активов. Сервер сайта
AIUpdateSvc.журнал Записывает взаимодействие точки синхронизации аналитики активов с облачной службой. Сервер системы сайта
AIUSMSI.log Записывает сведения об установке роли системы сайта точки синхронизации аналитики активов. Сервер системы сайта
AIUSSetup.log Записывает сведения об установке роли системы сайта точки синхронизации аналитики активов. Сервер системы сайта
ManagedProvider.журнал Записывает сведения об обнаружении программного обеспечения со связанным тегом идентификации программного обеспечения. Также регистрирует деятельность, связанную с инвентаризацией оборудования. Сервер системы сайта
MVLSImport.log Записывает сведения об обработке импортированных файлов лицензирования. Сервер системы сайта

Файлы журнала консоли Configuration Manager

Используйте указанные ниже файлы журнала для устранения проблем, связанных с консолью Configuration Manager.

Имя файла журнала консоли SCCM Описание Расположение файла журнала консоли
ConfigMgrAdminUISetup.log Записывает установку консоли Configuration Manager. Компьютер, на котором запущена консоль Configuration Manager
SmsAdminUI.log Записывает информацию о работе консоли Configuration Manager. Компьютер, на котором запущена консоль Configuration Manager
Smsprov.log Записывает действия поставщика SMS. Сервер сайта или сервер системы сайта

Файлы журнала точки управления SCCM

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

Имя файла журнала точки управления SCCM
Описание Расположение файла журнала MP
CcmIsapi.журнал Записывает действия клиента по обмену сообщениями на конечной точке. Сервер системы сайта. Сервер системы сайта
CCM_STS.log Записывает действия для маркеров проверки подлинности из Azure Active Directory или маркеров клиента, выданных сайтом. Сервер системы сайта. Сервер системы сайта
ClientAuth.log Записывает действия по подписанию и аутентификации. Сервер системы сайта. Сервер системы сайта
MP_CliReg.журнал Записывает действия по регистрации клиентов, обработанные точкой управления. Сервер системы сайта
MP_Ddr.log Записывает преобразование записей XML.ddr от клиентов и копирует их на сервер сайта. Сервер системы сайта
MP_Framework.log Записывает действия основной точки управления и компонентов клиентской инфраструктуры. Сервер системы сайта
MP_GetAuth.журнал Записывает состояние точек управления сайтом. Сервер системы сайта
MP_GetPolicy.log Записывает информацию о политике. Сервер системы сайта
MP_Hinv.log Преобразует записи инвентаризации оборудования XML от клиентов и копирует файлы на сервер сайта. Сервер системы сайта
MP_Location.log Записывает задачи диспетчера местоположения. Сервер системы сайта
MP_OOBMgr.журнал Записывает действия точки управления, связанные с получением OTP от клиента. Сервер системы сайта
MP_Policy.log Записывает информацию о политике. Сервер системы сайта
MP_RegistrationManager.log Записывает действия, связанные с регистрацией клиентов, такие как проверка сертификатов, CRL и токенов. Сервер системы сайта
MP_Relay.log Копирует файлы, полученные от клиента. Сервер системы сайта
MP_Retry.log Записывает повторные попытки инвентаризации оборудования. Сервер системы сайта
MP_Sinv.log Преобразует записи инвентаризации оборудования XML от клиентов и копирует их на сервер сайта. Сервер системы сайта
MP_SinvCollFile.log Записывает сведения о сборе файлов. Сервер системы сайта
MP_Status.журнал Записывает сведения о преобразовании файлов сообщений о состоянии XML.svf от клиентов и копиях этих файлов на сервер сайта. Сервер системы сайта
mpcontrol.log Записывает регистрацию точки управления в WINS. Регистрирует доступность точки управления каждые 10 минут. Сервер сайта
mpfdm.log Записывает действия компонента точки управления, который перемещает клиентские файлы в соответствующую папку INBOXES на сервере сайта. Сервер системы сайта
mpMSI.log Записывает сведения об установке точки управления. Сервер сайта
MPSetup.log Записывает процесс установки оболочки точки управления. Сервер сайта
UserService.log Записывает запросы пользователей из центра программного обеспечения, извлекая / устанавливая доступные пользователю приложения с сервера. Сервер системы сайта

Файлы журналов точки обслуживания хранилища данных

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

Имя файла журнала точки обслуживания хранилища данных Описание Расположение файла журнала DW
DWSSMSI.log Записывает сообщения, созданные при установке точки обслуживания хранилища данных. Сервер системы сайта
DWSSSetup.log Записывает сообщения, созданные при установке точки обслуживания хранилища данных. Сервер системы сайта
Майкрософт.ConfigMgrDataWarehouse.log Записывает информацию о синхронизации данных между базой данных сайта и базой данных хранилища данных. Сервер системы сайта

Файлы журнала резервной точки состояния

Файлы журнала резервной точки состояния перечислены ниже.

Имя файла журнала резервной точки состояния Описание Расположение файла журнала резервной точки состояния
FspIsapi.журнал Записывает сведения о связи с резервной точкой состояния от устаревших клиентов мобильных устройств и клиентских компьютеров. Сервер системы сайта
fspMSI.log Записывает сообщения, созданные при установке резервной точки состояния. Сервер системы сайта
fspmgr.log Записывает действия для роли системы сайта резервной точки состояния. Сервер системы сайта

Файлы журнала управления мобильными устройствами

  • DmClientHealth.log — записывает идентификаторы GUID всех клиентов мобильных устройств, которые обмениваются данными с точкой управления устройством.
  • DmClientRegistration.log — Записывает запросы на регистрацию от клиента мобильного устройства и ответы на него в основном режиме.
  • DmpDatastore.log — записывает все подключения к базе данных сайта и запросы, сделанные точкой управления устройством.
  • DmpDiscovery.log — записывает все данные обнаружения от клиентов мобильных устройств в точке управления устройством.
  • DmpFileCollection.log — записывает данные о сборе файлов мобильных устройств от клиентов мобильных устройств в точке управления устройством.
  • DmpHardware.log — записывает данные инвентаризации оборудования от клиентов мобильных устройств в точке управления устройством.
  • DmpIsapi.log — Записывает данные связи мобильного устройства от клиентов устройства в точке управления устройством.
  • dmpMSI.log — записывает данные MSI для настройки точки управления устройством.
  • DMPSetup.log — записывает процесс настройки управления мобильным устройством.
  • DmpSoftware.log — записывает данные о распространении программного обеспечения мобильных устройств от клиентов мобильных устройств в точке управления устройством.
  • DmpStatus.log — Записывает данные сообщений о состоянии мобильного устройства от клиентов мобильного устройства в точке управления устройством.
  • FspIsapi.log — Записывает данные передачи резервной точки состояния от клиентов мобильных устройств и клиентских компьютеров в резервной точке состояния.

Файлы журналов клиента мобильного устройства

  • DmCertEnroll.log — записывает данные о регистрации сертификатов на клиентах мобильных устройств.
  • DMCertResp.htm (in temp) — записывает ответ в формате HTML от сервера сертификатов, когда программа Enroller мобильного устройства запрашивает сертификат аутентификации клиента на клиентах мобильных устройств.
  • DmClientSetup.log — Записывает данные настройки клиента на клиентах мобильных устройств.
  • DmClientXfer.log — Записывает данные о передаче клиентов для развертываний Центра устройств Windows Mobile и ActiveSync.
  • DmCommonInstaller.log — записывает установку файла передачи клиента для настройки файлов передачи клиента мобильного устройства на клиентских компьютерах.
  • DmInstaller.log — записывает, правильно ли DMInstaller вызывает DmClientSetup и завершается ли DmClientSetup успешно или неудачно на клиентах мобильных устройств.
  • DmInvExtension.log — регистрирует установку файла расширения инвентаризации для настройки файлов расширения инвентаризации на клиентских компьютерах.
  • DmSvc.log — Записывает данные службы управления мобильными устройствами на клиентах мобильных устройств.

Файлы журнала развертывания операционной системы

  • CCMSetup.log — предоставляет информацию о действиях клиентской операционной системы.
  • CreateTSMedia.log — предоставляет информацию о носителе последовательности задач при его создании. Этот журнал создается на компьютере, на котором запущена консоль администратора Configuration Manager 2007.
  • DriverCatalog.log — предоставляет информацию о драйверах устройств, которые были импортированы в каталог драйверов.
  • MP_ClientIDManager.log — предоставляет информацию о точке управления Configuration Manager 2007, когда она отвечает на запросы идентификатора клиента Configuration Manager 2007 с загрузочного носителя или PXE. Этот журнал создается в точке управления Configuration Manager 2007.
  • MP_DriverManager.log — предоставляет информацию о точке управления Configuration Manager 2007, когда она отвечает на запрос действия последовательности задач «Автоматическое применение драйвера». Этот журнал создается в точке управления Configuration Manager 2007.
  • MP_Location.log — предоставляет информацию о точке управления Configuration Manager 2007, когда она отвечает на запросы к хранилищу состояний или выпускает запросы к хранилищу состояний от точки миграции состояния. Этот журнал создается в точке управления Configuration Manager 2007.
  • Pxecontrol.log — предоставляет информацию о диспетчере управления PXE.
  • PXEMsi.log — предоставляет информацию о точке обслуживания PXE и ​​создается при создании сервера сайта точки обслуживания PXE.
  • PXESetup.log — предоставляет информацию о точке обслуживания PXE и ​​создается при создании сервера сайта точки обслуживания PXE.
  • Setupact.log Setupapi.log Setuperr.log Предоставляет информацию о Windows Sysprep и журналы установки.
  • SmpIsapi.log — предоставляет информацию об ответах на запросы клиента Configuration Manager 2007 точки миграции состояния.
  • Smpmgr.log — предоставляет информацию о результатах проверки работоспособности точки миграции состояния и изменениях конфигурации.
  • SmpMSI.log — предоставляет информацию о точке миграции состояния и создается при создании сервера сайта точки миграции состояния.
  • Smsprov.log — предоставляет информацию о провайдере SMS.
  • Smspxe.log — предоставляет информацию о точке обслуживания PXE Configuration Manager 2007.
  • SMSSMPSetup.log — предоставляет информацию о точке миграции состояния и создается при создании сервера сайта точки миграции состояния.
  • Smsts.log — общее расположение для всех событий журнала развертывания операционной системы и последовательности задач.
  • TaskSequenceProvider.log — предоставляет информацию о последовательностях задач при их импорте, экспорте или редактировании.
  • Журнал USMT loadstate.log — предоставляет информацию о средстве миграции пользовательской среды (USMT), касающуюся восстановления данных пользовательской среды.
  • Журнал USMT scanstate.log — предоставляет информацию о USMT, касающуюся сбора данных о состоянии пользователя.

Файлы журнала защиты доступа к сети

  • Ccmcca.log — регистрирует обработку оценки соответствия на основе обработки политики NAP Configuration Manager и содержит обработку исправлений для каждого обновления программного обеспечения, необходимого для соответствия.
  • CIAgent.log — отслеживает процесс исправления и соответствия. Однако файл журнала обновлений программного обеспечения, * Updateshandler.log, предоставляет более информативные сведения об установке обновлений программного обеспечения, необходимых для соответствия требованиям.
  • locationservices.log — используется другими функциями Configuration Manager (например, информация о назначенном клиенту сайте), но также содержит информацию, относящуюся к защите доступа к сети, когда клиент находится в процессе исправления.Он записывает имена необходимых серверов исправления (точка управления, точка обновления программного обеспечения и точки распространения, на которых размещается контент, необходимый для соответствия), которые также отправляются в заявлении о работоспособности клиента.
  • SDMAgent.log — совместно с Configuration Manager предоставляет возможность управления желаемой конфигурацией и содержит процесс отслеживания исправлений и соответствия. Однако файл журнала обновлений программного обеспечения Updateshandler.log предоставляет более информативные сведения об установке обновлений программного обеспечения, необходимых для соответствия требованиям.
  • SMSSha.log — основной файл журнала для клиента защиты доступа к сети Configuration Manager, содержащий объединенную информацию о работоспособности из двух компонентов Configuration Manager: служб определения местоположения (LS) и агента соответствия конфигурации (CCA). Этот файл журнала также содержит информацию о взаимодействиях между агентом работоспособности системы Configuration Manager и агентом NAP операционной системы, а также между агентом работоспособности системы Configuration Manager и агентом соответствия конфигурации и службами определения местоположения.Он предоставляет информацию о том, успешно ли инициализирован агент NAP, данные о работоспособности и ответ о работоспособности.

Файлы журналов, относящиеся к пакетам и программам

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

Файл журнала пакета Описание Расположение файла журнала
colleval.log Записывает сведения о том, когда коллекции создаются, изменяются и удаляются оценщиком коллекций. Сервер сайта
execmgr.log Записывает сведения о запущенных пакетах и ​​последовательностях задач. Клиентский компьютер

Файлы журнала точек валидатора работоспособности системы

  • Ccmperf.log — содержит информацию об инициализации счетчиков производительности точки проверки работоспособности системы.
  • SmsSHV.log — основной файл журнала для точки проверки работоспособности системы; регистрирует основные операции службы проверки работоспособности системы, такие как ход инициализации.
  • SmsSHVADCacheClient.log — содержит информацию о получении ссылок на состояние работоспособности Configuration Manager из доменных служб Active Directory.
  • SmsSHVCacheStore.log — содержит информацию о хранилище кэша, используемом для хранения ссылок на состояние работоспособности Configuration Manager NAP, полученных из доменных служб Active Directory, таких как чтение из хранилища и удаление записей из файла хранилища локального кэша. Хранилище кеша не настраивается.
  • SmsSHVRegistrySettings.log — записывает любые динамические изменения в конфигурации компонента средства проверки работоспособности системы во время работы службы.
  • SmsSHVQuarValidator.log — Записывает клиентское заявление о состоянии здоровья и операциях обработки. Чтобы получить полную информацию, измените раздел реестра LogLevel с 1 на 0 в следующем месте: HKLMSOFTWAREMicrosoftSMSSHVLogging @ GLOBAL

Файлы журнала управления требуемой конфигурацией

  • ciagent.log — предоставляет информацию о загрузке, хранении и доступе к назначенным базовым показателям конфигурации.
  • dcmagent.log — предоставляет высокоуровневую информацию об оценке назначенных базовых показателей конфигурации и желаемых процессах управления конфигурацией.
  • discovery.log — предоставляет подробную информацию о процессах языка моделирования служб (SML).
  • sdmagent.log — предоставляет информацию о загрузке, хранении и доступе к содержимому элемента конфигурации.
  • sdmdiscagent.log — предоставляет высокоуровневую информацию о процессе оценки объектов и параметров, настроенных в указанных элементах конфигурации.

Файлы журнала пробуждения по локальной сети

Имя файла журнала сервера WOL Описание Расположение файла журнала WOL
Wolmgr.log Содержит информацию о процедурах пробуждения, таких как время пробуждения рекламных объявлений или развертываний, настроенных для пробуждения по локальной сети Сервер сайта SCCM
WolCmgr.log Содержит информацию о том, каким клиентам необходимо отправить пакеты пробуждения, количество отправленных пакетов пробуждения и количество повторных попыток пакетов пробуждения. Сервер сайта SCCM

Файлы журнала сервера сайта обновлений программного обеспечения

  • ciamgr.log — предоставляет информацию о добавлении, удалении и изменении элементов конфигурации обновления программного обеспечения.
  • distmgr.log — предоставляет информацию о репликации пакетов развертывания обновлений программного обеспечения.
  • objreplmgr.log — предоставляет информацию о репликации файлов уведомлений об обновлениях программного обеспечения с родительских на дочерние сайты.
  • PatchDownloader.log — предоставляет информацию о процессе загрузки обновлений программного обеспечения из источника обновлений, указанного в метаданных обновлений программного обеспечения, в место загрузки на сервере сайта.
  • replmgr.log — предоставляет информацию о процессе репликации файлов между сайтами.
  • smsdbmon.log — предоставляет информацию о том, когда элементы конфигурации обновления программного обеспечения вставляются, обновляются или удаляются из базы данных сервера сайта, и создает файлы уведомлений для компонентов обновлений программного обеспечения.
  • SUPSetup — Предоставляет информацию об установке точки обновления программного обеспечения. По завершении установки точки обновления программного обеспечения в этот файл журнала записывается сообщение «Установка прошла успешно».
  • WCM.log — предоставляет информацию о конфигурации точки обновления программного обеспечения и подключении к серверу Windows Server Update Services (WSUS) для категорий обновлений, классификаций и языков, на которые оформлена подписка.
  • WSUSCtrl.log — предоставляет информацию о конфигурации, подключении к базе данных и работоспособности сервера WSUS для сайта.
  • wsyncmgr.log — Предоставляет информацию о процессе синхронизации обновлений программного обеспечения.

Файлы журнала сервера WSUS

Имя файла журнала сервера WSUS Описание Расположение файла журнала WSUS
Журнал изменений Предоставляет информацию об измененной информации базы данных сервера WSUS. Сервер WSUS
Распространение программного обеспечения.журнал Предоставляет информацию об обновлениях программного обеспечения, которые синхронизируются из настроенного источника обновлений с базой данных сервера WSUS. Сервер WSUS

Обновления программного обеспечения Файлы журналов клиентского компьютера

  • CAS.log — предоставляет информацию о процессе загрузки обновлений программного обеспечения в локальный кэш и управления кешем.
  • CIAgent.log — предоставляет информацию об обработке элементов конфигурации, включая обновления программного обеспечения.
  • LocationServices.log — предоставляет информацию о расположении сервера WSUS при запуске сканирования на клиенте.
  • PatchDownloader.log — предоставляет информацию о процессе загрузки обновлений программного обеспечения из источника обновлений в место загрузки на сервере сайта. Этот журнал находится только на клиентском компьютере, настроенном в качестве узла синхронизации для Inventory Tool for Microsoft Updates.
  • PolicyAgent.log — предоставляет информацию о процессе загрузки, компиляции и удаления политик на клиентских компьютерах.
  • PolicyEvaluator — предоставляет информацию о процессе оценки политик на клиентских компьютерах, включая политики из обновлений программного обеспечения.
  • RebootCoordinator.log — предоставляет информацию о процессе координации перезапусков системы на клиентских компьютерах после установки обновлений программного обеспечения.
  • ScanAgent.log — предоставляет информацию о запросах на сканирование для обновлений программного обеспечения, о том, какой инструмент запрашивается для сканирования, о расположении WSUS и т. Д.
  • ScanWrapper — предоставляет информацию о предварительных проверках и инициализации процесса сканирования для Inventory Tool для обновлений Microsoft на клиентах Systems Management Server (SMS) 2003.
  • SdmAgent.log — предоставляет информацию о процессе проверки и распаковки пакетов, содержащих информацию об элементах конфигурации для обновлений программного обеспечения.
  • ServiceWindowManager.log — предоставляет информацию о процессе оценки настроенных окон обслуживания.
  • smscliUI.log — предоставляет информацию о взаимодействиях пользователя с панелью управления Configuration Manager, таких как запуск цикла сканирования обновлений программного обеспечения из диалогового окна свойств Configuration Manager, открытие монитора загрузки программ и т. Д.
  • SmsWusHandler — предоставляет информацию о процессе сканирования для Inventory Tool для обновлений Microsoft на клиентских компьютерах SMS 2003.
  • StateMessage.log — предоставляет информацию о том, когда сообщения о состоянии обновлений программного обеспечения создаются и отправляются в точку управления.
  • UpdatesDeployment.log — предоставляет информацию о развертывании на клиенте, включая активацию обновления программного обеспечения, оценку и принудительное применение. Подробное ведение журнала показывает дополнительную информацию о взаимодействии с клиентским пользовательским интерфейсом.
  • UpdatesHandler.log — предоставляет информацию о проверке соответствия обновлений программного обеспечения, а также о загрузке и установке обновлений программного обеспечения на клиенте.
  • UpdatesStore.log — предоставляет информацию о статусе соответствия для обновлений программного обеспечения, которые были оценены во время цикла проверки соответствия.
  • WUAHandler.log — предоставляет информацию о том, когда агент обновления Windows на клиенте выполняет поиск обновлений программного обеспечения.
  • WUSSyncXML.log — предоставляет информацию об инструменте инвентаризации для процесса синхронизации обновлений Microsoft.Этот журнал находится только на клиентском компьютере, настроенном в качестве узла синхронизации для Inventory Tool for Microsoft Updates.

Файл журнала агента Центра обновления Windows

  • WindowsUpdate.log — предоставляет информацию о том, когда агент обновления Windows подключается к серверу WSUS и получает обновления программного обеспечения для оценки соответствия, а также о наличии обновлений для компонентов агента.

Что такое веб-сервер? — Изучите веб-разработку

В этой статье мы объясняем, что такое веб-серверы, как работают веб-серверы и почему они важны.

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

  1. С аппаратной стороны веб-сервер — это компьютер, на котором хранится программное обеспечение веб-сервера и файлы компонентов веб-сайта. (например, документы HTML, изображения, таблицы стилей CSS и файлы JavaScript) Веб-сервер подключается к Интернету и поддерживает физический обмен данными с другими устройствами, подключенными к Интернету.
  2. Что касается программного обеспечения, веб-сервер включает в себя несколько частей, которые контролируют, как веб-пользователи получают доступ к размещенным файлам.Как минимум, это HTTP-сервер . HTTP-сервер — это программное обеспечение, которое распознает URL-адреса (веб-адреса) и HTTP (протокол, используемый вашим браузером для просмотра веб-страниц). Доступ к HTTP-серверу можно получить через доменные имена веб-сайтов, которые он хранит, и он доставляет содержимое этих размещенных веб-сайтов на устройство конечного пользователя.

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

Для публикации веб-сайта вам понадобится статический или динамический веб-сервер.

Статический веб-сервер , или стек, состоит из компьютера (оборудования) и HTTP-сервера (программного обеспечения). Мы называем это «статическим», потому что сервер отправляет свои размещенные файлы в ваш браузер как есть.

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

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

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

Файлы хостинга

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

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

  • Выделенный веб-сервер обычно более доступен. (в рабочем состоянии)
  • За исключением простоев и неполадок в системе, выделенный веб-сервер всегда подключен к Интернету.
  • Выделенный веб-сервер может иметь один и тот же IP-адрес все время. Это известно как выделенный IP-адрес .(не все интернет-провайдеры предоставляют фиксированный IP-адрес для домашних линий)
  • Выделенный веб-сервер обычно обслуживается третьей стороной.

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

Если у вас есть услуга веб-хостинга, вы должны загрузить свои файлы на свой веб-сервер.

Обмен данными через HTTP

Во-вторых, веб-сервер обеспечивает поддержку HTTP ( H и t ext T ransfer P rotocol). Как следует из названия, HTTP определяет, как передавать гипертекст (связанные веб-документы) между двумя компьютерами.

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

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

HTTP предоставляет четкие правила взаимодействия клиента и сервера. О самом HTTP мы поговорим позже в технической статье. А пока помните об этих вещах:

  • Только клиентов могут делать HTTP-запросы, и то только серверам .Серверы могут только ответить на HTTP-запрос клиента .
  • При запросе файла через HTTP клиенты должны предоставить URL-адрес файла.
  • Веб-сервер должен отвечать на каждый HTTP-запрос , по крайней мере, с сообщением об ошибке.

На веб-сервере HTTP-сервер отвечает за обработку входящих запросов и ответы на них.

  1. При получении запроса HTTP-сервер сначала проверяет, соответствует ли запрошенный URL-адрес существующему файлу.
  2. Если да, веб-сервер отправляет содержимое файла обратно в браузер. В противном случае сервер приложений создает необходимый файл.
  3. Если ни один из процессов невозможен, веб-сервер возвращает браузеру сообщение об ошибке, чаще всего 404 Not Found . Ошибка 404 настолько распространена, что некоторые веб-дизайнеры тратят много времени и усилий на создание страниц с ошибкой 404.

Статический и динамический контент

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

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

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

Теперь, когда вы знакомы с веб-серверами, вы можете:

Пошаговое руководство по настройке сервера пассивного сайта

SCCM

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

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

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

( Примечание: Это требует выполняется как на активном, так и на пассивном серверах сайта)

Из-за текущих выпусков последних наборов ADK, 1903 год последняя версия для Windows ADK, а также последняя версия Windows 10, пишущая это гид.

ADK 1903 больше не содержит Windows PE в качестве надстройки, только на версия 1809 и предыдущие выпуски, поэтому вам нужно будет установить Windows PE 1809 первый. Без этого проверка предварительных условий не удастся.

Загрузить Windows ADK 1809 Win-PE можно здесь — https://go.microsoft.com/fwlink/?linkid=2087112

1. Дважды щелкните файл adksetup.exe

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

( Примечание: Это требует выполняется как на активном, так и на пассивном серверах сайта)

Загрузить Windows ADK 1903 можно здесь — https: // go.microsoft.com/fwlink/?linkid=2086042

1. Дважды щелкните файл adksetup.exe

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

( Примечание: Это требует будет выполняться на Активном первичном сайте.)

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

1. Перейдите в Администрирование — Конфигурация сайта — Серверы и роли системы сайта

2. Выделите сервер первичного сайта

3. В разделе «Роли системы сайта» щелкните правой кнопкой мыши Роль точки распространения и щелкните Удалить роль

.

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

( Примечание: Если Параметр «Управление библиотекой содержимого» выделен серым цветом, потому что вы не удалили роль точки распространения)

1.Зайдите в Администрирование — Конфигурация сайта — Сайтов

2. На вкладке «Главная страница» щелкните «Сайт» — «Управление содержимым». Библиотека

3. Введите удаленное местоположение, в которое вы переместите в библиотеку содержимого и нажмите «Далее».

4. На вкладке сводки обновите ее, и вы сможет увидеть индикатор выполнения в процентах. Вы также можете просмотреть журнал distmgr.log для просмотра его прогресса в режиме реального времени.

1. Щелкните правой кнопкой мыши Серверы и роли сервера сайта и нажмите Create Site System Server

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

3. Прокси: Укажите прокси-сервер Интернета Нажмите следующие

4. Система Выбор роли: Укажите роли для этого сервера — Выберите сервер сайта в пассивный режим, затем нажмите следующий

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

6. Резюме : Мастер создаст новый сервер системы сайта со следующими настройками — Нажмите рядом, чтобы начать.

7. Перейдите в Мониторинг — Статус сервера сайта, чтобы проверьте установку.При нажатии кнопки «Показать статус» будет отображаться ход выполнения.

1. Откройте консоль Configuration Manager

.

2. Перейдите в Администрирование — Конфигурация сайта — Сайтов

3. Щелкните вкладку «Узлы» под

.

4. Щелкните правой кнопкой мыши пассивный сервер сайта и выберите Сделать активным

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

Высокая доступность сайта | Блог о технологиях Microsoft

Высокая доступность сервера сайта

С помощью System Center Configuration Manager вы можете иметь роль резервирования с несколькими экземплярами роли (точка распространения,…). Configuration Manager 1806 позволяет обеспечить высокую доступность для роли сервера сайта (это невозможно до версии Configuration Manager 1806). Для сайта центра администрирования и дочернего первичного сайта вам потребуется версия 1810 Configuration Manager.

Благодаря этой возможности вы можете получить следующие преимущества:

  • Избыточность для роли сервера сайта
  • Обслуживание вашего сервера (смена оборудования, обновление вашей ОС и т. Д.) Стало проще
  • Таким образом, миграция локального сервера в Azure упрощается.

Сервер сайта в пассивном режиме

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

Предварительные требования

Для установки сервера сайта в пассивном режиме необходимы следующие условия:

  • Библиотека содержимого сайта присутствует в удаленном сетевом ресурсе. Оба сервера сайта имеют разрешения полного доступа к общему ресурсу.
  • Сервер сайта не может выполнять роль точки распространения.
  • Два сервера сайта должны быть присоединены к одному серверу.
  • Два сервера сайта должны использовать одну и ту же базу данных сайта. Сервер базы данных должен быть удален от каждого сервера сайта.
  • Два сервера сайта должны иметь роль системного администратора на экземпляре SQL Server. Новому серверу сайта необходим доступ к базе данных сайта.
  • Роль точки подключения службы не может быть установлена ​​на обоих серверах сайта.

Для сервера сайта в пассивном режиме необходимы следующие предварительные требования:

  • Установлены все необходимые компоненты для первичного сайта (.Net Framework, удаленное разностное сжатие,…) Вы можете использовать эту ссылку для просмотра списка всех предварительных требований. Список всех предварительных требований.
  • Добавьте учетную запись компьютера в группу локальных администраторов на сервере сайта в активном режиме.
  • Необходимо установить с использованием исходных файлов, соответствующих версии сервера сайта в активном режиме.

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

Миграция ролей

Миграция сервера базы данных сайта

Откройте приглашение Dos и выполните команду и получите доступ к папке, в которой находится файл preinst.exe (ConfigMgrFolderInstallation \ bin \ x64 \ 00000409 ConfigMgrFolderInstallation 9000CM, папка SCH0008 является папкой установлен

Выполните команду Preinst / Stopsite . Эта команда позволяет остановить все службы на этом сайте перед резервным копированием базы данных.

Откройте SQL Management Studio для резервного копирования базы данных SCCM. Щелкните правой кнопкой мыши базу данных и выберите Задачи, и Резервное копирование… .

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

Когда резервное копирование будет завершено, появится новая Windows. Нажмите ОК , чтобы закрыть Windows.

Теперь можно приступить к восстановлению. Скопируйте резервную копию на новый SQL Server.

Убедитесь, что интеграция CRL включена.Создайте новый запрос и запустите процедуру sp_configure clr enabled.

Щелкните правой кнопкой мыши узел «База данных» и выберите «Восстановить базу данных».

Выберите переключатель «Устройство» и щелкните значок, чтобы выбрать файл резервной копии.

Щелкните Добавить и выберите файл резервной копии. Щелкните OK

Щелкните OK, чтобы запустить операцию.

База данных добавлена ​​на сервер. Теперь вы можете настроить свою базу данных SQL.

Откройте новый запрос в новостях SQL Server и запустите:

  --- Включите SQL Broker в базе данных сайта
Мастер ИСПОЛЬЗОВАНИЯ;
ИДТИ
ALTER DATABASE CM_NIB SET ENABLE_BROKER
ИДТИ
--- УСТАНОВИТЕ базу данных сайта как заслуживающую доверия
Мастер ИСПОЛЬЗОВАНИЯ;
ИДТИ
ALTER DATABASE CM_NIB SET TRUSTWORTHY ON
ИДТИ
--- УСТАНОВИТЕ базу данных для соблюдения HONOR_BROKER_PRIORITY
Мастер ИСПОЛЬЗОВАНИЯ;
ИДТИ
ALTER DATABASE CM_NIB SET HONOR_BROKER_PRIORITY ON;
ИДТИ
  

Убедитесь, что конфигурация применена.Запустите команду. Замените ‘CM_NIB’ на имя своей базы данных

  выберите имя, collation_name, user_access_desc, is_read_only, state_desc, is_trustworthy_on, is_broker_enabled, is_honor_broker_priority_on из sys.databases559, где теперь можно настроить 90CM_CM_N09000, чтобы использовать 9682M 90CM_NO теперь можно настроить 90CM_NIB, где name = ' новый SQL Server. На сервере сайта запустите  Install of Configuration Manager  в меню Windows. 

Появится новый мастер, нажмите Далее . Выберите Выполнить обслуживание сайта или сбросьте этот сайт и нажмите Далее

Выберите Изменить конфигурацию SQL Server и нажмите Далее

Введите полное доменное имя нового SQL-сервера.Убедитесь, что учетная запись компьютера является членом локальной группы администраторов вашего нового SQL Server, и нажмите Next

Начало настройки…

Перезагрузите новый SQL Server и сервер сайта. Модификация применена.

Миграция точки распространения

Для миграции точки распространения вы можете добавить новую точку распространения в свою инфраструктуру SCCM. Сервер, который получает роль DP (точка распространения), должен иметь эти роли и функции Windows.

  • Веб-сервер (IIS): / ISAPI Extensions
  • Веб-сервер (IIS): / ASP.NET 3.5
  • Веб-сервер (IIS): / ASP.NET 4.5
  • Веб-сервер (IIS ): Безопасность / Аутентификация Windows
  • Веб-сервер (IIS): Инструменты управления / Совместимость управления IIS 6 / Совместимость с метабазами IIS 6
  • Веб-сервер (IIS): Инструменты управления / Совместимость управления IIS 6 / Совместимость с IIS 6 WMI
  • Удаленное дифференциальное сжатие

Теперь вы можете добавить точку распространения.В Configuration Manager щелкните Administration и Sites . Щелкните Добавить роли системы сайта .

Выберите желаемую подачу с помощью кнопки Обзор .

Выберите роль точки распространения и нажмите Далее.

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

В Boudary Windows выберите желаемую Boundary Group и запустите

Вы можете проверить журнал SCCM (Distmgr.log) нет ошибок с конфигурацией новой точки распространения. Вы также можете использовать консоль sccm. Щелкните Monitoring / Состояние конфигурации точки распространения / «YourDistributionPoint» / Подробности

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

Перенос поставщика SMS

Перед установкой поставщика SMS необходимо установить ADK (та же версия ADK на сервер сайта).Необходимо установить средства развертывания , средства миграции пользовательской среды (USMT) и среду предустановки Windows (Windows PE).

После установки ADK вы можете переместить поставщика SMS. На сервере сайта щелкните «Настройка диспетчера конфигураций».

Появится новый мастер, нажмите Далее . Выберите Выполнить обслуживание сайта или сбросьте этот сайт и нажмите Далее

В Обслуживание сайта Windows отметьте Изменить конфигурацию поставщика SMS и нажмите Далее

Введите имя нового сервера и щелкните Next .

Выполняется настройка….

По завершении вы можете повторно выполнить эту операцию для удаления роли на старом сервере.

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

Высокая доступность для сервера сайта

Перед настройкой высокой доступности для роли сервера сайта пассивный сервер должен иметь роль системного администратора в экземпляре SQL. На SQL Server откройте SQL Management Studio и создайте новый запрос. Запустите этот запрос, чтобы добавить новый сервер (сервер в пассивном режиме) в группы SYSADMIN. Замените Formation \ SRV-SCCM2 $ своим доменным именем AD и именем сервера в пассивном режиме.

  ИСПОЛЬЗОВАТЬ [главный]
ИДТИ
СОЗДАТЬ ВХОД [Formation \ SRV-SCCM2 $] ИЗ WINDOWS С DEFAULT_DATABASE = [master],
DEFAULT_LANGUAGE = [us_english]
ИДТИ
ИЗМЕНИТЬ РОЛЬ СЕРВЕРА [системный администратор] ДОБАВИТЬ УЧАСТНИКА [Formation \ SRV-SCCM2 $]
ИДТИ
  

Два сервера сайта должны иметь доступ к базе данных sql сайта. Этот доступ есть у первого сервера. Поэтому вам нужно добавить только второй сервер. В SQL Management Studio выполните следующий запрос. Замените CM_NIB на имя вашей базы данных, а Formation \ SRV-SCCM2 $ на ваше доменное имя AD и имя сервера в пассивном режиме.

  ИСПОЛЬЗОВАТЬ [CM_NIB]
ИДТИ
СОЗДАТЬ ПОЛЬЗОВАТЕЛЯ [Formation \ SRV-SCCM2 $] ДЛЯ ВХОДА [Formation \ SRV-SCCM2 $] С DEFAULT_SCHEMA = [dbo]
ИДТИ
  

Вы должны установить на сервере сайта в пассивном режиме предварительные требования для сайта и сайта системы.

  • Удаленное дифференциальное сжатие

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

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

На консоли SCCM щелкните Administration / Site Configuration / Sites / Manage Content Library

В поле New Location введите путь к ранее созданному общему ресурсу. Введите имя папки после сетевого пути. Я выбрал имя Content, но вы можете настроить желаемое имя.Щелкните Move .

Вы можете использовать журнал DistMgr.log для проверки модификации.

Когда новое расположение библиотеки содержимого было настроено, сервер сайта в пассивном режиме был добавлен. На консоли SCCM щелкните Administration / Site Configuration / Sites и щелкните Create Site System Server .

Появятся новые окна, нажмите кнопку Обзор и выберите сервер сайта в пассивном режиме.

Проверьте Site Server в пассивном режиме и щелкните Next .

Выберите нужный вариант для исходного файла Configuration Manager и установки. Я выбираю Копировать исходные файлы установки по сети с сервера сайта в активном режиме . Укажите папку для установки нового сервера сайта и щелкните Далее .

Вы можете запустить следующую операцию и проверить ее с помощью журнала. FailOverMgr.

Оставить комментарий

Добавить комментарий

Ваш адрес email не будет опубликован.

© 2019 Штирлиц Сеть печатных салонов в Перми

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