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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цена

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

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

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

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

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

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

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

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

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!#a3cup@1$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:j2jkUFDF6OGGqxkgg7Hk3ilbZI@ec2-54-243-201-144.compute-1.amazonaws.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(ilk6@4sfdofb=b_2ht@vad*$ehh9-)3u_83+y%(+phh&=

Setting DJANGO_SECRET_KEY and restarting locallibrary... done, v7
DJANGO_SECRET_KEY: eu09(ilk6@4sfdofb=b_2ht@vad*$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). Когда клиенту предоставляется отдельная физическая машина.

4. CMS-хостинг. Специальные тарифы, оптимизированные под 1С-Битрикс, Joomla и WordPress.
5. Премиум хостинг. С неограниченным трафиком и 100% нагрузкой на одно ядро процессора.
6. Продажа SSL-сертификатов. Sectigo, Thawte, Let’s Encrypt.
7. Регистрация доменов. Доступно более 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

• 05.04.2021
• Читать 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

Применимо к: 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 .

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

  --- Включите 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;
ИДТИ
  

  выберите имя, 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.