Iis основные сведения о кластеризации


Содержание

Кластерные информационные системы.

Кластерные информационные системы.

Все ведущие компьютерные компании (Compaq, Dell, Hewlett-Packard, IBM, Sun Microsystems), предлагают собственные кластерные решения. Лидирующие позиции в сегменте UNIX-кластеров занимала IBM, которая активно продвигала свою базу данных DB2, фирма Sun активно продвигала свое решение Sun Cluster. Одним из наиболее активных игроков (как по числу сертифицированных для кластеров платформ, так и по разнообразию самих кластерных решений) признают корпорацию Compaq, которая предлагала практически полный ассортимент кластеров на платформах Windows для отдела или удаленного филиала, для применений в инфраструктуре корпорации и для крупных центров обработки данных. Например, кластерное решение Compaq TrueCluster Server максимально удовлетворяло современным требованиям, предъявляемым компаниями к подобной технологии. Кластерное ПО позволяет, например, устанавливать базу данных на нескольких связанных вместе серверах. Необходимость в таком объединении возникает, например, если требуется большая емкость или нужно сократить время простоя в случае сбоя на сервере, что достигается за счет переноса операций на другой сервер кластера. Это позволяет значительно сократить затраты на аппаратные платформы, делая экономически оправданным построение кластеров из недорогих серверов стандартной архитектуры даже для относительно небольших предприятий. Compaq и Oracle активно сотрудничают в области технологий и бизнеса, что позволит создать более масштабируемую, управляемую, надежную и экономичную кластерную платформу баз данных. Кроме того, Oracle начала сотрудничать с Dell и Sun Microsystems, которые предлагали заказчикам предварительно сконфигурированные и протестированные системы, работающие с ПО кластеризации от Oracle. Dell (например, кластерное программное обеспечение на протестированных серверах с ОС Windows и Linux).

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

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

— за слаженную работу всех серверов;

— за разрешение возникающих в системе конфликтов,

— обеспечивает формирование и реконфигурацию кластера после сбоев;

— обеспечивает распределение нагрузки по узлам кластера;

— обеспечивает восстановление работы приложений сбойных серверов на доступных узлах (failover — процедура миграции);

— осуществляет мониторинг состояния аппаратной и программной сред;

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

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

К кластерным решениям в современных вычислительных системах кроме повышенной надежности и быстродействия, предъявляются еще несколько дополнительных требований:

— они должны обеспечивать единое внешнее представление системы,

— высокую скорость резервного копирования и восстановления данных,

— параллельный доступ к БД,

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

— иметь средства настройки высокого уровня готовности, гарантировать восстановление после аварии.

Конечно, использование нескольких узлов кластера, которые одновременно обращаются к одним и тем же данным, увеличивает сложность процедуры резервного копирования и последующего восстановления информации. Перенос нагрузки с аварийного узла на исправный — это основной механизм обеспечения непрерывной работы приложений при условии оптимального использования ресурсов кластера. Для эффективной совместной работы кластерных систем и СУБД система должна иметь распределенный менеджер блокировок, обеспечивающий непротиворечивое изменение базы данных при поступлении последовательности запросов с разных узлов кластера. Настройка конфигурации кластера с одновременным обеспечением высокой доступности приложений является достаточно сложным процессом (это связано со сложностью определения правил, по которым те или иные приложения переносятся с аварийных узлов кластера на исправные). Кластерная система обязана позволять легко переносить приложения с одного узла кластера на другой, а также восстанавливать аварийное приложение на другом узле. Пользователь системы не обязан знать о том, что он работает с кластерной системой, поэтому для пользователей кластер должен выглядеть как единый компьютер. Он должен иметь единую файловую систему для всех узлов, единый IP-адрес и единое ядро системы.

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

Windows Server 2012: строим отказоустойчивый кластер с двумя узлами

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

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации. Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows. Отказоустойчивая кластеризация — часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом. Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere. В данной статье используются два физических сервера, но этапы настройки кластера для физических и виртуальных узлов одни и те же. Ключевая особенность заключается в том, что узлы должны быть настроены одинаково, чтобы резервный узел мог выполнять рабочие нагрузки в случае аварийного переключения или динамической миграции. Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

Рисунок. Просмотр компонентов кластера

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

  • Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение — она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
  • В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
  • Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx? > Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Добавление функций отказоустойчивой кластеризации

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 — добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012. Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1. В результате будет запущен мастер добавления ролей и компонентов.

Экран 1. Запуск мастера добавления ролей и компонентов

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1. Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next. Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента. Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов. Щелкните Next.

Экран 2. Добавление средства отказоустойчивого кластера и инструментов

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения. При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера. Этот процесс необходимо выполнить на обоих узлах.


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

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

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.

Экран 3. Запуск мастера проверки конфигурации

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты. По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера. Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера. Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком «X» в случае серьезных ошибок. С предупреждениями следует ознакомиться, но их можно игнорировать. Серьезные ошибки необходимо исправить перед созданием кластера.

Экран 4. Просмотр отчета о проверке

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

На данном этапе можно создать кластер, начиная с любого узла кластера. Я организовал кластер, начав на первом узле (WS2012-N1).

Чтобы создать новый кластер, выберите ссылку Create Cluster на панели Management или панели Actions, как показано на экране 5.

Экран 5. Запуск мастера создания кластера

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

Экран 6. Выбор серверов для кластера

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес — 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

Экран 7. Настройка точки доступа кластера

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

Экран 8. Подтверждение параметров, выбранных при создании кластера

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

Мастер создания кластера автоматически выбирает хранилище для кворума, но часто он выбирает не тот диск кворума, который хотелось бы администратору. Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks. Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт. Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings. В результате появится мастер выбора конфигурации кворума, с помощью которого можно изменить параметры кворума кластера.

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV). В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks. Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9). Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

Экран 9. Добавление CSV

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

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

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности. Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10. Выберите роль и нажмите кнопку Next.

Экран 10. Добавление роли виртуальной машины

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

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

Пример настройки хранилища iSCSI

Для отказоустойчивого кластера Windows Server 2012 требуется общее хранилище, которое может быть типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В данном отказоустойчивом кластере используется Channel SAN.

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator


Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.

Размышления о кластеризации. Часть 1 — Понятие кластер

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

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

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

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

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

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

Самым простым вариантом является использование двух серверов:

Это самый базовый вариант кластера. Никаких дополнительных устройств. Сайт резолвится через ip адрес web сервера. В настройках сайта/приложения указывается ip адрес сервера баз данных для подключения к БД.

Принцип работы показан на следующей схеме:

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

Updated: August 12, 2014

You May Also Enjoy

Установка nginx из исходников

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

Уникальные IP адреса в access.log Apache

less than 1 minute read

Получить список уникальных IP адресов в лог файле вэбсервера Apache можно с помощью:

Установка WireShark на Ubuntu 16.04/14.04

less than 1 minute read

WireShark предоставляет удобный функционал для анализа сетевого трафика.

Проблемы с ttf-mscorefonts-installer на Ubuntu 16.04

Сегодня меня в конец достало назойливое уведомление о том, что ttf-mscorefonts-installer не смог установить все, что ему нужно.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

IIS (Internet Information Services)

Internet Information Services
Разработчики: Microsoft
Постоянный выпуск: 10 / 29 July 2015 года ; 4 years ago ( 2015-07-29 )
Состояние разработки: Active
Написана на: C++ (язык программирования) [1]
Операционная система: Windows NT
Локализация: Same languages as Windows
Тип ПО: Web server
Лицензия: Part of Windows NT (same license)
Веб-сайт iis .net

IIS (англ. Internet Information Services ) является Visual Basic приложением, которое располагается на веб-сервере и отвечает на запросы браузера. Приложение IIS использует HTML для представления своего пользовательского интерфейса и использует скомпилированый код Visual Basic для обработки запросов и реагирования на события в браузере. Для пользователя приложение IIS представляется рядом страниц HTML. Для разработчика приложение IIS состоит из особого типа объекта, называемого WebClass, который в свою очередь, содержит ряд ресурсов, называемых webitems. WebClass выступает в качестве центрального функционального блока приложения, обрабатывающего данные из браузера и отправляющего информацию пользователям. Разработчик описывает ряд процедур, которые определяют, каким образом WebClass отвечает на эти запросы. webitems являются HTML-страницами и другими данными, которые WebClass может отправить в браузер в ответ на запрос.

Содержание

Архитектура

Internet Information Services (IIS) 7 и выше обеспечивает архитектуру обработки запросов, которая включает в себя:

  • Служба активации процесса Windows (WAS), который позволяет сайтам использовать отличающиеся от HTTP и HTTPS протоколы.
  • Веб-движок сервера, который может быть изменен путем добавления или удаления модулей.
  • Интегрированные конвейеры обработки запросов от IIS и ASP.NET.


Компоненты

IIS содержит несколько компонентов, которые выполняют важные функции для приложений и ролей веб-сервера в Windows Server® 2008 (IIS 7.0) и Windows Server 2008 R2 (IIS 7.5). Каждый компонент имеет функции, такие как прослушивание запросов к серверу, управление процессами и чтение файлов конфигурации. Эти компоненты включают в себя обработчики протокола, такие как HTTP.sys и службы, такие как World Wide Web Publishing (служба WWW) и службы активации процесса Windows (WAS).

Internet Information Server (IIS) имеет свой собственный ASP.NET Process Engine для обработки запроса ASP.NET. Способ настройки приложения ASP.NET зависит от того, какая версия IIS приложения используется.

Internet Information Server (IIS) включает в себя набор программ для создания и администрирования веб-приложений, поисковых систем, а также поддержку для написания веб-приложений, обеспечивающих доступ к базам данных, таким как SQL Server. IIS позволяет настроить компьютер в качестве веб-сервера и предоставляет функциональные возможности для разработки и развертывания веб-приложений ASP.NET на сервере. Кроме того, возможно установить параметры безопасности для конкретного веб-сайта для конкретных пользователей и компьютера для того, чтобы защитить его от несанкционированного доступа.

По заявлениям разработчиков, IIS повышает доступность веб-сайтов и приложений при одновременном снижении системного администрирования и стоимости развертывания. IIS 7.5 поддерживает HTTP, HTTPS, FTP, FTPS, SMTP и NNTP.

Ключевые особенности

  • Встроенные расширения
    • WebDAV и FTP
    • Фильтрация запросов
    • Модули администрирования
  • Усовершенствования управления
    • Анализатор соответствия рекомендациям
    • Windows PowerShell провайдер и cmdlets
    • Ведение журнала конфигурации и трассировки
  • Улучшения хостинга приложений
    • Управляемые учетные записи служб
    • Hostable веб-ядро
    • Трассировка неудачных запросов для FastCGI
  • Улучшения .NET поддержки для Server Core

Установка

  • Нажмите кнопку Пуск и выберите Панель управления.
  • На панели управления выберите Программы, а затем Включение и отключение компонентов Windows.
  • В диалоговом окне «Компоненты Windows» нажмите Службы IIS, а затем кнопку ОК.

Конфигурирование

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

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните правой кнопкой мыши веб-узел, который необходимо настроить, на левой панели и выберите команду Свойства.
  5. Перейдите на вкладку веб-узел .
  6. В поле Описание введите описание веб-узла.
  7. Введите адрес Internet Protocol (IP) для веб-узла или оставьте значение по умолчанию все (не назначено) .
  8. Измените порт протокола управления передачей (TCP), соответствующим образом.
  9. Перейдите на вкладку Домашний каталог.
  10. Чтобы использовать папку на локальном компьютере, выберите каталог на данном компьютере и нажмите кнопку Обзор, чтобы найти папку, которую требуется использовать.
  11. Чтобы использовать папку, общий ресурс с другого компьютера в сети, выберите параметр Общая папка другого компьютера и затем введите путь или нажмите кнопку Обзор, чтобы выбрать общую папку.
  12. Нажмите кнопку Чтение предоставить доступ на чтение к папке (обязательно).
  13. Нажмите кнопку ОК, чтобы принять свойства веб-сайта.

Создание нового веб-узла:

Чтобы создать новый веб-узел на сервере Apache, необходимо настроить виртуальный узел и настроить отдельные параметры для узла. Если используются службы IIS, можно создать новый веб-узел путем перевода следующих терминов в эквивалентные термины IIS:

Apache термин Термин IIS
Корень документа Каталог домашней страницы веб-узла IIS
Имя_сервера Заголовок узла IIS
Прослушивание IIS IP-адрес и TCP-порт

Чтобы создать новый веб-узел в IIS, выполните следующие действия:

  1. Войдите в систему на компьютере веб-сервера с правами администратора.
  2. Нажмите кнопку Пуск, выберите Настройка и щелкните Панель управления.
  3. Дважды щелкните значок Администрирование, а затем дважды щелкните значок Диспетчер служб Интернета.
  4. Щелкните Действие, выберите пункт Создать и выберите веб-узел.
  5. После запуска мастера создания веб-узла, нажмите кнопку Далее.
  6. Введите описание веб-узла. Это описание используется для идентификации веб-узла в диспетчере служб Интернета только для внутренних целей.
  7. Выберите IP-адрес для веб-узла. Если выбрать все (без значения), веб-узел будет доступен для всех интерфейсов и всех настроенных IP-адресов.
  8. Введите номер порта TCP, чтобы опубликовать на нем сайт.
  9. Введите имя заголовка узла (реальные имя, которое используется для доступа к этому узлу).
  10. Нажмите кнопку Далее.
  11. Введите путь к папке, которая содержит документы веб-узла, или нажмите кнопку Обзор, выберите папку и нажмите кнопку Далее.
  12. Укажите права доступа для веб-узла и нажмите кнопку Далее.
  13. Нажмите кнопку Готово.

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

  • Главная
  • Отказоустойчивая кластеризация — общие сведения.

Отказоустойчивая кластеризация — общие сведения.

  • Автор: Уваров А.С.

  • 03.06.2014

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

Начнем с того, что термин отказоустойчивый не совсем применим к кластерным решениям, он возник в результате неверного перевода термина failover cluster. Правильный перевод — с обработкой отказа, хотя сегодня все чаще употребляется иной термин — высокой доступности (high availability), который, на наш взгляд, наиболее точно отражает суть дел.

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

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

Во-первых это служебная сеть кластера для передачи сигнала «пульса» (heartbeat), по которому кластер следит за состоянием своих узлов (на схеме показана красным), сеть хранения данных (SAN, синяя), в недорогих решениях это чаще всего iSCSI через отдельную Ethernet-сеть, но это может быть также и FibreChanell или иные технологии. Для обслуживания клиентов кластер включается в существующую локальную сеть.

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

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

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

Если в качестве хранилища используется iSCSI, то служебную сеть кластера и сеть хранения данных можно объединить. Но при этом у нас остается точка отказа — сеть, поэтому в ответственных системах следует использовать для доступа к SAN не менее двух сетей. Кроме повышения надежности данный подход позволяет повысить пропускную способность, что тоже актуально.

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

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

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

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

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

В наших следующих материалах мы рассмотрим практическую реализацию отказоустойчивого кластера на базе Hyper-V.

Кластер серверов

Кластер серверов (Server Cluster) — это определенное количество серверов, объединенных в группу и образующих единый ресурс. Данное решение позволяет существенно увеличить надежность и производительность системы.

Сгруппированные в локальную сеть несколько компьютеров можно назвать аппаратным кластером, однако, суть данного объединения — повышение стабильности и работоспособности системы за счет единого программного обеспечения под управлением модуля (Cluster Manager).

Общая логика кластера серверов создается на уровне программных протоколов и дает возможность:

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

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

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

Принято считать, что кластеры серверов делятся на две модели:

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

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

Смотрите также:

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

КЛАСТЕРИЗАЦИЯ СТРАНИЦ ВЕБ-САЙТА НА ОСНОВЕ МЕТАДАННЫХ ВЕБ-АНАЛИТИКИ

студент магистратуры института прикладных информационных технологий и коммуникаций, СГТУ имени Гагарина Ю.А.,

канд. физ.-мат. наук, доц. кафедры информационно-коммуникационные системы и программная инженерия, СГТУ имени Гагарина Ю.А.,

АННОТАЦИЯ

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


Ключевые слова: веб-сайт, семантическая кластеризация, метаданные, ключевые слова, веб-аналитика.

Введение

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

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

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

Ряд работ в области семантической кластеризации страниц веб-сайтов использует в качестве существенного элемента гипертекстовые связи между страницами. Так, например, в статье [7] представлена математическая модель гипертекстовой структуры в виде взвешенного редуцированного графа и предложен метод семантической кластеризации гипертекстовой структуры, использующий данные статистики переходов пользователей между страницами сайта. В работе [4] эксперименты по кластеризации страниц веб-сайта проводились также для графовой модели сайта, но с использованием алгоритмов MLC [6].

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

Сбор данных о действиях пользователей на веб-сайте

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

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

  • сбор информации с помощью программы анализа логов (лог-анализатор). В этом случае накапливаются журнальные файлы с данными о посещаемости сайта на отдельном компьютере. Все эти файлы аналитик сам собирает и анализирует. Самые популярные лог-анализаторы: Webalizer и WebTrends и другие.
  • использование сервиса обработки данных (счетчик интернет-статистики). Здесь все данные группируются в отдельном журнале загрузок элемента web-ресурса посторонним лицом (поставщиком счетчика), обрабатываются и передаются в читаемом виде пользователю сервиса. Самые популярные счетчики на сегодняшний момент средства такого рода: Google Analytics, Яндекс Метрика, Ливинтернет и другие [3].

В данной работе используется сервис Google Analytics — это бесплатный набор современных инструментов веб аналитики, предоставляемый известной корпорацией Google для создания детальной статистики посетителей сайтов.

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

  • просмотры страниц – общее количество страниц, просмотренных посетителями. Учитываются повторные просмотры одной страницы.
  • уникальные просмотры страниц – это количество сеансов, в ходе которых определенная страница была просмотрена хотя бы один раз.
  • средняя длительность просмотра страницы – среднее количество времени, в течение которого пользователи просматривают заданную страницу/экран или набор страниц/экранов.
  • процент отказов – это процент посещений, в ходе которых было открыто не более одной страницы, т.е. при которых посетитель покидает сайт со страницы входа.
  • процент выходов – процент выходов с сайта, выполненных с указанной страницы или набора страниц [2].

На рисунке 1 изображен отчет по страницам сайта sstu.ru, который представлен с помощью сервиса Google Analytics.

Рисунок 1. Статистика по страницам веб-сайта sstu.ru. Каждая строка таблицы содержит набор метаданных для каждой страницы

Для получения данных из Google Analytics использовался сервис Query Explorer, который представляется по адресу: https://ga-dev-tools.appspot.com/query-explorer/. Данные были собраны с сайта www.sstu.ru, за период с 1 мая 2020 по 1 мая 2020.

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

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

Рисунок 2. Фрагмент таблицы с данными статистики по страницам веб-сайта, преобразованных в формат xlsx для более удобной последующей обработки

Семантическая кластеризация страниц веб-сайта

Кластеризация данных проводилась с помощью программного пакета Statistica. На сегодняшний день в продукте Statistica Data Miner представлен набор методов кластеризации с возможностью представления большого нобора графиков и процедур визуализации. Для эффективнго визуального представления данных для кластеризации был выбран метод агломеративной иерархической кластеризации. Результаты иерархической кластеризации в виде дендрограммы представлены на рисунке 3.

Рисунок 3. Дендограмма результатов кластеризации

На рисунке 4 представлен фрагмент таблицы разбиения страниц веб-сайта с помощью пакета Statistica, в последнем столбце указано к какому кластеру относится конкретная страница. В данном примере число кластеров равно 6.

Рисунок 4. Результаты разбиения веб-страниц сайта на 6 кластеров с помощью Statistica. Последний столбец таблицы «Membership» содержит информацию о номере кластера, к которому отнесена страница

В результате кластеризации мы получили набор шести кластеров (дендроидный алгоритм позволяет нам остановить кластеризацию на любом этапе). Далее необходимо было выяснить является ли разбиение случайным или можно выделить нечто семантически общее для каждого кластера. С этой целью был написан скрип на языке Python, который вычисляет плотность ключевых слов страницы без стоп-слов и выбирает только часто встречаемые используяя сайт seogift.ru – инструмент проверки плотности ключевых слов (параметр минимального числа вхождений слов можно указать при вызове скрипта). В результате выполнения скрипта, на выходе получаем объединение ключевых слов, характерных для каждого кластера и число вхождений слова в кластере. В таблице 1 приведен набор наиболее часто встречаемых ключевых слов характеризующих каждый кластер и семантическое описание каждого кластера на основе этих ключевых слов.

Таблица 1.

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

Ключевые слова и частота их появления в кластере

Установка и конфигурирование IIS

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

В этой и следующих статьях мы рассмотрим различные варианты развертывания. Однако во всех случаях основные предпосылки остаются неизменными. На рабочей станции имеется готовый веб-сайт, который нужно развернуть на сервере, чтобы он был доступен клиентам. Для ASP.NET таким сервером является , а его текущей версией — IIS 8. Когда он был впервые реализован, IIS представлял собой базовый веб-сервер. С годами IIS развился в сложный сервер приложений, предоставляющий широкое множество функциональных средств, наиболее важным из которых является поддержка хостинга приложений ASP.NET.

В этой статье основное внимание уделяется IIS 8. Хотя машина, на которой запущен IIS 8, здесь называется сервером, IIS можно запускать под управлением версий Windows как для рабочей станции, так и для сервера. На рабочих станциях доступны не все, но большинство функциональных возможностей, что позволяет размещать сложные веб-сайты. По возможности мы рекомендуем использовать Windows Server, однако недорогой альтернативой могут послужить Windows 7 или Windows 8.

В Microsoft привязывают выпуски IIS с выпусками Windows. В состав Windows Server 2008 и Windows Vista входит версия IIS 7.0, в состав Windows Server 2008 R2 и Windows 7 — версия IIS 7.5, а в состав Windows Server 2012 и Windows 8 — IIS 8. Версии — 7.0 и 7.5 — в Microsoft обобщенно называют IIS 7, что может вносить путаницу. Версию IIS, поддерживаемую операционной системой, изменить нельзя — Windows Server 2008 будет использовать только IIS 7.0. Например, модернизировать ее до версии IIS 7.5, используемой в Windows Server 2008 R2, не получится.


Установка IIS

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

Установка IIS на настольных версиях Windows (Windows Vista, Windows 7 и Windows 8)

Каждая версия операционной системы Windows предлагает свою версию IIS — IIS 8 (в Windows 8), IIS 7.5 (в Windows 7) или IIS 7 (в Windows Vista). Во всех этих версиях Windows, IIS включен, но изначально не установлен. Чтобы установить его, необходимо выполнить следующие действия:

Откройте панель управления.

Нажмите кнопку «Включение или отключение компонентов Windows». Теперь вам нужно подождать, пока Windows исследует вашу систему.

Найдите элемент Internet Information Services (Службы IIS) в верхней части списка и нажмите на галочку чтобы включить его:

Обратите внимание, что Windows позволяет включить множество компонентов IIS: поддержка FTP-сервера, дополнительные инструменты управления, службы обратной совместимости с IIS 6 и т.д.

Убедитесь, что вы выбрали поддержку ASP.NET. Для этого раскройте узел Службы Интернета Компоненты разработки приложений ASP.NET (Internet Information Services World Wide Web Services Application Development Features ASP.NET):

Если вы хотите использовать поддержку IIS в Visual Studio, которая позволяет вам создавать виртуальные каталоги IIS непосредственно в диалоговом окне New Web Site, вам нужно выбрать пункт «Совместимость управления IIS 6» в разделе «Средства управления веб-сайтом» (Web Management Tools IIS 6 Management Compatibility).

Как только вы выбрали нужные параметры IIS, нажмите кнопку OK для завершения установки.

Установка IIS в Windows Server 2008

Установка и настройка IIS одинакова для Windows Server 2008 и Windows Server 2008 R2. Необходимые шаги описаны ниже:

Запустите диспетчер сервера. Чтобы сделать это, нажмите кнопку Start и выберите All Programs Administrative Tools Server Manager.

Выберите узел Roles в дереве слева.

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

Выполните необходимые действия в мастере. Вас вероятно попросят установить дополнительные необходимые роли — если это так, нужно просто принять операции и продолжить.

После установки вам будет предложено настроить веб-сервер. Как в настольных версиях Windows, вы можете выбрать специфические особенности IIS 7, которые должны быть включены.

Если вы работаете в ASP.NET с версией .NET Framework 4.5, то эту версию .NET Framework необходимо будет установить (центр разработчиков .NET Framework)

Установка IIS в Windows Server 2012

Процесс установки IIS в Windows Server 2012, по существу, такой же, как и в Windows Server 2008. Основное различие заключается в том, что пользовательский интерфейс несколько отличается. Подробное описание вы можете найти перейдя по ссылке Installing IIS 8 on Windows Server 2012.

Управление IIS

При установке IIS, он автоматически создает каталог с именем C:\inetpub\wwwroot, который представляет ваш веб-сайт. Все файлы в этом каталоге будет отображаться, как будто они находятся в корневом каталоге вашего веб-сервера.

Чтобы добавить дополнительные страницы на ваш веб-сервер, можно скопировать файлы HTML, ASP или ASP.NET напрямую в каталог C:\Inetpub\wwwroot. Например если добавить файл TestFile.html в этот каталог, вы можете запросить его в браузере через URL-адрес http://localhost/TestFile.html. Вы даже можете создавать вложенные папки для группирования связанных ресурсов. Например, вы можете получить доступ к C:\inetpub\wwwroot\MySite\MyFile.html через браузер, используя URL-адрес http://localhost/MySite/MyFile.html.

Каталог wwwroot удобен для запуска простых примеров и статичных страниц. Для правильного использования ASP.NET вы должны сделать свой собственный виртуальный каталог для каждого веб-приложения, которое вы создаете. Например, вы можете создать папку с любым именем на любом диске вашего компьютера и поместить ее в виртуальный каталог IIS как будто она расположена в каталоге C:\inetpub\wwwroot.

Прежде чем начать работу, вам нужно запустить диспетчер служб IIS. Его можно найти в меню Start (Пуск). Конкретное расположение может зависеть от используемой версии Windows (IIS Диспетчер служб IIS). Ярлык программы будет располагаться в разделе Programs (Программы) или Administrative Tools (Администрирование). Начальная страница IIS Manager показана на рисунке ниже:

Теперь нужно ознакомиться с рядом терминов, используемых в IIS. В левой части окна IIS Manager отображается запись с именем используемого сервера. Наш сервер имеет имя PROFESSORWEB, сгенерированное по умолчанию Windows 8, которое будет использоваться в большинстве примеров. В центральной области отображается представление сервера. Это представление отображает набор значков, которые позволяют конфигурировать параметры сервера. В правой части экрана расположен список доступных действий. Например, в этом представлении можно запускать, останавливать и перезапускать сервер.

Если развернуть элемент сервера в древовидном представлении в левой части экрана, отобразится элемент Sites (Сайты), содержащий единственную запись Default Web Site (Веб-сайт по умолчанию). Сайт — это коллекция файлов и каталогов, образующих веб-сайт. На одном сервере IIS может поддерживать несколько сайтов, как правило, на различных портах TCP/IP (по умолчанию используется порт 80). Сочетание имени сервера и порта сайта образует первую часть URL-адреса. Например, при использовании сервера mywebserver с сайтом, подключенным к порту 80, URL-адрес выглядит следующим образом:

Каждый сайт может содержать множество файлов и каталогов. Каждый из них образует часть URL-адреса. Так, URL-адрес статической страницы mypage.html, расположенной в каталоге myfiles, будет следующим:

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

Чтобы проверить работоспособность IIS выберите Default Web Site и в правой области диспетчера служб IIS выберите пункт «Запустить». После этого нажмите кнопку «Обзор *.80 (http)» чтобы открыть страницу сайта в браузере:

Как видите, в моем случае я поменял порт используемый по умолчанию (с 80 на 8080). Я сделал это, т.к. на 80-м у меня запущен локальный Apache-сервер. Если у вас возникает такая же проблема, то изменить порт можно щелкнув правой кнопкой мыши по сайту (Default Web Site) и выбрав в контекстном меню «Изменить привязки» (Bindings). После этого в диалоговом окне можно изменить порт, используемый по умолчанию.

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

Iis основные сведения о кластеризации

Обновлен: Ноябрь 2007

В этом разделе описывается перемещение веб-приложений из IIS версии 6.0 в IIS 7.0. Веб-приложение в IIS 7.0 может быть настроено на использование в классическом или интегрированном режиме. В классическом режиме поддерживается обратная поддержка с ранними версиями IIS путем использования расширения ISAPI для вызова среды выполнения ASP.NET. Этот параметр часто предполагает минимальные изменения (или их отсутствие) в существующих приложениях.

Интегрированный режим IIS 7.0 является унифицированным конвейером обработки запросов, который объединяет конвейер запросов ASP.NET с базовым конвейером запросов IIS. Интегрированный конвейер обеспечивает улучшенную производительность, модульность при настройке и администрировании, а также гибкость расширения IIS модулями с управляемым кодом. Например, можно указать модуль с управляемым кодом в папке App_Code веб-приложения и зарегистрировать его для ответа на все запросы IIS (включая запросы статических файлов).


Использование интегрированного режима IIS 7.0 может предполагать внесение небольших изменений в файл Web.config. Небольшие изменения могут также потребоваться, если приложение использует любые пользовательские модули с интерфейсом IHttpModule .

Общие сведения относительно конвейера обработки запросов в интегрированном режиме IIS 7.0 см. в разделе Общие сведения о жизненном цикле приложения ASP.NET для служб IIS 7.0 . При использовании IIS 7.0 приложения могут выполняться на сервере как в классическом, так и интегрированном режиме. И классический, и интегрированный режимы поддерживают .NET Framework, версия 2.0 и более поздние версии. .NET Framework версии 1.1 поддерживается только в классическом режиме. Для получения более подробной информации относительно обновления IIS до IIS 7.0 см. документ Обновление приложений ASP.NET до IIS 7.0: различия между встроенным и классическим режимами IIS 7.0 (на английском языке).

Информация в данном разделе может использоваться для перемещения веб-приложений из IIS 5.x в IIS 7.0. Вместе с тем могут потребоваться дополнительные изменения (не описанные в данном документе). Дополнительные сведения см. на странице Обновление ASP.NET 1.1 IIS7 в Windows Server 2003, Windows XP и Windows 2000.

В этом разделе содержатся следующие подразделы:

При переводе веб-приложения ASP.NET в интегрированный режим IIS 7.0 необходимо обновить файл Web.config. IIS 7.0 предполагает изменения, необходимые для возможности администрирования файлов Web.config, и изменения в типах параметров, хранящихся в файлах Web.config. Новые параметры сохраняются в разделе конфигурации system.webServer .

В IIS 6.0 оснастка ASP.NET MMC предоставляет функции администрирования IIS, позволяющие настраивать ASP.NET. Дополнительные сведения см. в разделе Пошаговое руководство. Настройка приложений ASP.NET в IIS 6.0 с помощью консоли управления (MMC) .

В IIS 7.0 администрирование приложений ASP.NET более интегрировано с администрированием IIS (без отдельной оснастки). Вместо этого настройка IIS и ASP.NET выполняется при помощи IIS Manager. Так как данные конфигурации IIS 7.0 сохраняются в системе конфигураций .NET Framework, файл Web.config приложения, которое выполняется в IIS 7.0, содержит параметры веб-сервера и ASP.NET. Например, в файле Web.config приложения ASP.NET, которое выполняется в IIS 7.0, можно указать файл по умолчанию, в который будет осуществляться переход, если обозреватель не запрашивает определенный файл. (В IIS 6.0 и более ранних версиях это обеспечивалось при помощи параметра в метабазе IIS.)

Редактирование файлов Web.config

Файл Web.config веб-приложения, выполняющегося в IIS 7.0, можно редактировать следующим образом:

Непосредственным редактированием файла Web.config, при помощи Visual Studio или Visual Web Developer, или же при помощи текстового редактора.

При помощи IIS Manager. Дополнительные сведения см. в разделе Диспетчер Internet Information Services (IIS).

Использование средства администрирования веб-узла ASP.NET. Дополнительные сведения см. в разделе Средство администрирования веб-узла ASP.NET .

Примечание.

Изменения в средстве администрирования веб-узла не влияют на дочерние элементы конфигурации в system.webServer .

Использование средства командной строки служб IIS 7.0 (Appcmd.exe). Данная служебная программа позволяет вводить параметры конфигурации IIS и веб-приложения в командной строке. Дополнительные сведения см. в разделе Программа командной строки IIS 7.0 (IIS 7.0 Command-Line Tool).

Раздел system.webServer

Раздел конфигурации system.webServer в файле Web.config содержит параметры IIS 7.0, применяемые в веб-приложении. Раздел system.WebServer является дочерним элементом конфигурации. Дополнительные сведения см. на веб-странице IIS 7.0: system.webServer Section Group (IIS Settings Schema).

Примеры параметров веб-сервера, доступные для установки в группе настроек конфигурации system.WebServer , включают:

Стандартный документ, возвращаемый веб-сервером клиенту, если запрос не содержит указание на определенный ресурс (элемент defaultDocument ).

Параметр сжатия ответных сообщений (элемент httpCompression ).

Пользовательские заголовки (элемент customHeaders раздела httpProtocol ).

Модули (элемент modules ).

Обработчики (элемент handlers ).

Некоторые параметры применимы только в интегрированном режиме IIS 7.0 и неприменимы в классическом режиме. Например, если приложение выполняется в классическом режиме, все модули с управляемым кодом и обработчиками, указанными в разделе system.WebServer файла Web.config, будут проигнорированы. Вместо этого модули с управляемым кодом и обработчики должны быть описаны в ранних версиях IIS путем использования элементов httpModules и httpHandlers в разделе system.web.

Примеры использования раздела конфигурации system.webServer см. Практическое руководство. Настройка раздела для служб IIS 7.0 .

В общем случае перевод веб-приложений IIS 6.0 в классический режим IIS 7.0 предполагает перемещение в пул приложений, которые выполняются в классическом режиме. Например, при установке IIS 7.0 и веб-сервер по умолчанию сконфигурирован на работу в интегрированном режиме. Сервер также сконфигурирован на работу с стандартным пулом приложений DefaultAppPool . Чтобы запустить веб-приложение в классическом режиме, используйте приложение Classic.NETAppPool или создайте новый пул приложений, настроенный для работы в классическом режиме. Для получения более подробной информации относительно создания пула приложений см. раздел Создание пула приложений.

Все пользовательские модули, использующие интерфейс IHttpModule в приложениях в классическом режиме, уведомляются только о тех запросах конвейера, которые обрабатываются в среде выполнения ASP.NET. Например, о запросах страниц .aspx. Жизненный цикл приложения в классическом режиме является идентичным жизненному циклу ASP.NET в IIS 6.0. Дополнительные сведения см. в разделе Общие сведения о жизненном цикле приложения ASP.NET для IIS 5.0 и 6.0 .

Если приложение, которое выполняется в классическом режиме, содержит обработчик, требующий наличия карты сценариев для обработки пользовательского расширения в IIS, необходимо зарегистрировать обработчик как в группе httpHandler , так и в группе handler . Нужно сопоставить пользовательское расширение имени файла ASP.NET ISAPI (Aspnet_isapi.dll) указанием атрибутов modules и scriptProcessor в элементе handler . Эти атрибуты указывают, что модуль, описывающий обработчик, является расширением ISAPI, и указывают путь к расширению. Таким образом, в IIS 7.0 в классическом режиме обеспечивается обратная совместимость с более ранними версиями IIS. Вместе с тем при выполнении приложения в интегрированном режиме необходимо удалить атрибуты modules и scriptProcessor . Дополнительные сведения см. в разделе Практическое руководство. Настройка расширений для обработчиков HTTP-данных в IIS .

При переводе веб-приложения IIS 6.0 в классический режим работа без изменений в интегрированном режиме не гарантируется. Если приложение переводится из классического режима в интегрированный (и изменениях в пользовательских модулях и обработчиках), может потребоваться внести дополнительные изменения в приложение, которые обеспечат правильную работу в интегрированном режиме. Следующий раздел описывает процесс перевода приложения в интегрированный режим IIS 7.0.

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

Зарегистрировать пользовательские модули и обработчики в разделе system.webServer файла Web.config при помощи методов, описанных в разделе Миграция файла Web Config в интегрированный режим далее.

Определите обработчики событий для событий конвейера запросов HttpApplication , таких как BeginRequest и EndRequest , только в методе Init пользовательского модуля.

Убедитесь, что изучены все вопросы, описанные в разделе «Различия между интегрированным режимом и классическим режимом» документа Обновление приложений ASP.NET до IIS 7.0: различия между встроенным и классическим режимами IIS 7.0 (на английском языке).

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

При переводе приложения из классического в интегрированный режим можно оставить регистрацию пользовательских модулей и обработчиков в классическом режиме или удалить ее. Если регистрации httpModules и httpHandlers в классическом режиме не будут удалены, необходимо установить validation атрибутов элемента validateIntegratedModeConfiguration , чтобы избежать ошибок false . Элемент validation является дочерним для элемента system.webServer . Дополнительные сведения см. в подразделе «Отключение сообщения о миграции» (Disabling the migration error message) раздела Интеграция ASP.NET и служб IIS 7.0 (ASP.NET Integration with IIS 7.0).


Миграция файла Web.config в интегрированный режим

Если модуль или обработчик описаны на уровне приложений, модуль или обработчик не вызываются автоматически. Это относится к модулям и обработчикам, описанным в папке Bin folder или как исходный код в папке App_Code, и не описанным в разделе system.webServer файла Web.config. Чтобы обеспечить включение модуля или обработчика в конвейер обработки запросов в интегрированном режиме, необходимо зарегистрировать модуль (обработчик) одним из методом:

Непосредственно отредактировать файл Web.config, добавив элемент modules или handlers в элемент system.webServer . Следует учесть различия в имени элемента в классическом режиме — modules сравнивается с httpModules и с httpHandlers.

IIS Manager используется для изменения конфигурации модуля или обработчика. Более подробную информацию см. в разделах Конфигурация сопоставлений обработчиков в IIS 7.0 и Конфигурация модулей в IIS 7.0 (на английском языке).

Используйте программу командной строки IIS 7.0 (Appcmd.exe). Более подробную информацию см. в разделе Конфигурация параметров веб-узлов, приложений, виртуальных каталогов или URL-адресов при помощи Appcmd.exe(на английском языке).

Классы и свойства в интегрированном режиме

При работе с приложением в интегрированном режиме IIS 7.0 в версии.NET Framework 3.0 или более поздней можно использовать следующие классы и члены, недоступные в классическом режиме:

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

Свойство Headers объекта HttpResponse , предоставляющее доступ к заголовкам ответов.

Свойства IsPostNotification и CurrentNotification объекта HttpContext , которые используются при предоставлении обработчиков событий HttpApplication .

Свойства Headers и ServerVariables объекта HttpRequest , доступные для изменения.

Пресс-центр

Создание кластера на базе Windows 2000/2003. Шаг за шагом

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

Microsoft Windows 2000/2003 поддерживает две технологии кластеризации: кластеры с балансировкой нагрузки (Network Load Balancing) и кластеры серверов.

В первом случае (кластеры с балансировкой нагрузки) служба Network Load Balancing придает службам и приложениям свойства высокого уровня надежности и масштабируемости за счет объединения до 32 серверов в единый кластер. Запросы от клиентов в данном случае распределяются среди узлов кластера прозрачным образом. При отказе узла кластер автоматически изменяет свою конфигурацию и переключает клиента на любой из доступных узлов. Этот режим конфигурации кластера также называется active-active режимом, когда одно приложение работает на нескольких узлах.

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

Кластерный подход к организации внутренней сети дает следующие преимущества:

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

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

Системные рекомендации

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

  • Microsoft Windows 2000 Advanced (Datacenter) Server или Microsoft Windows 2003 Server Enterprise Edition, установленные на всех серверах кластера.
  • Установленная служба DNS. Немного поясню. Если вы строите кластер на основе двух контроллеров домена, то намного удобнее использовать службу DNS, которую вы в любом случае устанавливаете при создании Active Directory. Если вы создаете кластер на основе двух серверов, членов Windows NT домена, то вам придется использовать либо службу WINS, либо заносить соответствие имен и адресов машин в файл hosts.
  • Terminal Services для удаленного управления серверами. Не обязательно, но при наличии Terminal Services удобно управлять серверами со своего рабочего места.

Требования к аппаратному обеспечению

  • Аппаратное обеспечение для узла кластера лучше подбирать, основываясь на Cluster Service Hardware Compatible List (HCL). По рекомендациям Microsoft аппаратное обеспечение должно быть протестировано на совместимость с Cluster Services.
  • Соответственно вам понадобятся два сервера, имеющих по два сетевых адаптера; SCSI-адаптер, имеющий внешний интерфейс для подключения внешнего массива данных.
  • Внешний массив, имеющий два внешних интерфейса. Каждый из узлов кластера подключается к одному из интерфейсов.

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

Требования к сетевым настройкам


  • Уникальное NetBIOS имя для кластера.
  • Пять уникальных статических IP-адресов. Два для сетевых адаптеров на кластерную сеть, два для сетевых адаптеров на общую сеть и один для кластера.
  • Доменная учетная запись для кластерного сервиса (Cluster service).
  • Все узлы кластера должны быть либо member server в домене, либо контроллерами домена.
  • Каждый сервер должен иметь два сетевых адаптера. Один для подключения в общую сеть (Public Network), второй для обмена данными между узлами кластера (Private Network).

Замечание: по рекомендациям Microsoft ваш сервер должен иметь два сетевых адаптера, один для общей сети, второй для обмена данными внутри кластера. Можно ли строить кластер на одном интерфейсе — наверное, да, но я не пробовал.

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

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

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

Установка двухузлового кластера может быть разделена на 5 шагов

  • Установка и настройка узлов в кластере.
  • Установка и настройка разделяемого ресурса.
  • Проверка дисковой конфигурации.
  • Конфигурирование первого узла кластера.
  • Конфигурирование второго узла в кластере.

Это пошаговое руководство позволит вам избежать ошибок во время установки и сэкономить массу времени. Итак, начнем.

Установка и настройка узлов

Мы немного упростим задачу. Поскольку все узлы кластера должны быть либо участниками домена, либо контроллерами домена, то корневым держателем каталога AD (Active Directory) сделаем 1-й узел кластера, на нем же будет работать DNS-служба. 2-й узел кластера будет полноправным контроллером домена.

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

Сетевые настройки

Перед началом установки кластера и Active Directory необходимо выполнить сетевые настройки. Все сетевые настройки хочется разделить на 4 этапа. Для распознавания имен в сети желательно иметь DNS-сервер с уже существующими записями о серверах кластера.

Каждый сервер имеет по две сетевые карты. Одна сетевая карта будет служить для обмена данными между узлами кластера, вторая будет работать на клиентов в нашей сети. Соответственно первый назовем Private Cluster Connection, второй назовем Public Cluster Connection.

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

    My Network Places → Properties

Private Cluster Connection → Properties → Configure → Advanced

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

    Internet Protocol (TCP/IP) → Properties → Use the following IP: 192.168.30.1

(Для второго узла используйте адрес 192.168.30.2 ). Введите маску подсети 255.255.255.252 . В качестве адреса DNS-сервера для обоих узлов используйте адрес 192.168.100.1 .

  • Дополнительно на вкладке Advanced → WINS выберите пункт Disabled NetBIOS over TCP/IP . Для настроек сетевых адаптеров общей (Public) сети этот пункт опустите.
  • Проделайте то же самое с сетевой картой для локальной сети Public Cluster Connection. Используйте адреса, приведенные в таблице. Единственная разница в конфигурации двух сетевых плат состоит в том, что для Public Cluster Connection не требуется выключения режима WINS — NetBIOS over TCP/IP .
  • Для конфигурирования всех сетевых адаптеров на узлах кластера используйте следующую табличку:

    Примечание.
    Узел Сетевое имя IP address MASK DNS Server
    1 Public Cluster Connection 192.168.100.1 255.255.255.0 192.168.100.1
    1 Private Cluster Connection 192.168.30.1 255.255.255.252 192.168.100.1
    2 Public Cluster Connection 192.168.100.2 255.255.255.0 192.168.100.1
    3 Private Cluster Connection 192.168.30.2 255.255.255.252 192.168.100.1

    Установка Active Directory

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

    Установка Cluster User Account

    По рекомендациям Microsoft для Cluster Service следует создать отдельную учетную запись, от имени которой он будет работать. Эта учетная запись должна быть создана до установки Cluster Service:

    • Start → Programs → Administrative Tools → Active Directory Users and Computers
    • Добавьте нового пользователя, например, ClusterService.
    • Установите флажки на: User Cannot Change Password и Password Never Expires .
    • Также добавьте этого пользователя в группу администраторов и дайте ему права Log on as a service (права назначаются в Local Security Policy и Domain Controller Security Policy ).

    Настройка внешнего массива данных

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

    1. Оба сервера должны быть выключены, внешний массив включен, подсоединен к обоим серверам.
    2. Включаем первый сервер. Получаем доступ к дисковому массиву.
    3. Проверяем, чтобы внешний дисковый массив был создан как Basic. Если это не так, то переведем диск с помощью опции Revert to Basic Disk .
    4. Создаем на внешнем диске через Computer Manage-ment → Disk Management небольшой раздел. По рекомендациям Microsoft он должен быть не менее 50 Мб. Я рекомендую создать раздел в 500 Мб. или чуть больше. Для размещения кластерных данных этого вполне достаточно. Раздел должен быть отформатирован в NTFS.
    5. На обоих узлах кластера этот раздел будет назван одной буквой, например, Q. Соответственно при создании раздела на первом сервере выберем пункт Assign the following drive letter — Q .
    6. Оставшуюся часть диска вы можете разметить по своему желанию. Конечно, крайне желательно использовать файловую систему NTFS. Например, при настройке служб DNS, WINS основные базы служб будут перенесены на общий диск (не системный том Q, а второй, созданный вами). И по соображению безопасности вам будет удобнее использовать именно NTFS-тома.
    7. Закрываем Disk Management и проверяем доступ к вновь созданному разделу. Например, можно создать на нем текстовый файл test.txt , записать и удалить. Если все прошло нормально, то с конфигурацией внешнего массива на первом узле мы закончили.
    8. Теперь выключаем первый сервер. Внешний массив должен быть включен. Включаем второй сервер и проверяем доступ к созданному разделу. Также проверим, чтобы буква, назначенная первому разделу, была идентична выбранной нами, то есть Q.

    На этом конфигурация внешнего массива завершена.

    Установка Cluster Service Software

    Конфигурация первого узла кластера

    Перед началом установки Cluster Service Software все узлы кластера должны быть выключены, все внешние массивы должны быть включены. Перейдем к конфигурации первого узла. Внешний массив включен, первый сервер включен. Весь процесс установки происходит с использованием Cluster Service Configuration Wizard:

    Конфигурация второго узла кластера

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

    1. В диалоговом окне Create or Join a Cluster выберите The second or next node in the cluster и нажмите далее.
    2. Введите имя кластера, которое мы задали ранее (в примере это MyCluster), и нажмите далее.
    3. После подключения второго узла к кластеру Cluster Service Configuration Wizard автоматически заберет все установки с основного узла. Для запуска службы Cluster Service используйте имя, которые мы создавали ранее.
    4. Введите пароль вашей учетной записи и нажмите далее.
    5. В следующем диалоговом окне нажмите Finish для завершения установки.
    6. Cluster service будет запушен на втором узле.
    7. Закройте окно Add/Remove Programs .

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

    Постскриптум, благодарности

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

    Шаг Узел 1 Узел 2 Внешний массив Комментарий
    Установки сетевого окружения Включен Включен Выключен Оба узла кластера включены. Конфигурирование сетевых плат, сетевого окружения. При необходимости должен быть установлен Active Directory. Проверка настроек. Создание учетной записи для Cluster Service.
    Конфигурирование внешнего дискового массива Включен Выключен Включен Включены первый узел и дисковый массив. Создание томов на дисковом массиве. Проверка конфигурации.
    Проверка настроек дискового массива Выключен Включен Включен Первый узел выключен. Включены второй узел и дисковый массив. Проверка доступа к томам на дисковом массиве на втором узле. Конфигурация томов.
    Конфигурирование первого узла Включен Выключен Включен Включены первый узел и дисковый массив. Установка и настройка Cluster Service на первом узле.
    Конфигурирование второго узла Включен Включен Включен Включены первый и второй узел и внешний дисковый массив. Подключение второго узла в кластер, конфигурирование второго кластера.
    Завершение установки Включен Включен Включен Все включено. Проверка состояния кластера. Тесты на аварийное завершение узла кластера.

    Время реакции кластера на непредвиденные ситуации зависит от множества параметров. Это тип ресурса, свойства ресурса, свойства группы ресурсов и времени, необходимого ресурсу на загрузку. Например, загрузка базы данных сервера DHCP происходит достаточно быстро. Однако перевод Exchange-сервера может занять до нескольких секунд. Это время, необходимое Exchange-серверу произвести быструю проверку целостности базы и загрузить все необходимые компоненты. В частности, мы экспериментировали с серверами WINS и DHCP, длительность реакции на отказ сервиса не превышала 1.5 секунд. А время реакции Exchange-сервера составляла около 10 секунд, это выражалось в небольшом тайм-ауте в работе клиента.

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

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

    Илон Маск рекомендует:  mysql_connect - Открывает соединение с сервером MySQL
    Понравилась статья? Поделиться с друзьями:
    Кодинг, CSS и SQL