June 2009

You are currently browsing the monthly archive for June 2009.

Здесь будет идти речь о кластере Windows Server 2003 Enterprise Edition и о запуске в кластере службы MSMQ. MSMQ, как кластерный ресурс, зависит от двух кластерных ресурсов: сетевого имени и физического диска. Зависимость от сетевого имени позволяет идентифицировать кластерную группу по IP адресу, и позволяет клиентам обращаться к группе как к виртуальному серверу. Физический диск нужен для хранилища сообщений и очередей.


Без кластера, клиенты из сети должны подключаться к серверу по имени или IP адресу, подключаясь к приложению или службе. Служба кластера позволяет создать виртуальные сервера. В дополнение к клиентам MSMQ, работающим со стандартным, не кластерным сервером MSMQ, который обслуживается на узле кластера, написанное для работы в составе кластера приложение MSMQ может связаться с сервером MSMQ, который работает в контексте виртуального сервера. Виртуальный сервер MSMQ, это кластерная группа, состоящая из кластерного ресурса MSMQ и его зависимых ресурсов, о которых уже упоминалось выше. Виртуальный сервер MSMQ не привязан с определенному компьютеру, и в случае отказа он будет перемещён на другой узел, который станет обслуживать клиентов. Очереди создаются на виртуальном сервере, и сообщения можно посылать в очереди виртуального сервера, используя обычный синтаксис VirtualServerName\QueueName.


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


После установки MSMQ 3.0 на всех узлах кластера можно приступать к созданию кластерного ресурса MSMQ. Можно создавать несколько ресурсов MSMQ, но работа таких ресурсов выходит за рамки поддержки Майкрософт. Поэтому, желательно создавать только один ресурс MSMQ и потом его не переименовывать. После выбора ресурса физического диска в группу MSMQ (он должен быть доступен всем узлам кластера), на этом диске будет создано хранилище очередей, которое желательно создать в папке \msmq\storage. После создания хранилища, местоположение папки хранилища изменять не следует.


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


Если в процессе установки ресурса MSMQ возникнут проблемы, обратитесь к файлу журнала кластера, который обычно расположен по этой ссылке: %systemroot%\Cluster\cluster.log.


Для создания и настройки кластерного ресурса и группы MSMQ в качестве виртуального сервера выполните следующие действия:

  1. Нажмите Пуск (Start), выберете пункт Программы (All Programs), пункт Администрирование (Administrative Tools), и затем запустите программу Cluster Administrator.
  2. В пункте Open Connection to Cluster нужно выбрать соответствующее имя кластера.
  3. В дереве кластерных групп нужно выбрать ту кластерную группу, которой должен принадлежать ресурс MSMQ.
  4. После выбора группы, в пункте меню File нужно выбрать New, а затем щелкнуть Resource.
  5. В мастере New Resource Wizard заполните поля Name и Description, и выберете Message Queuing в списке Resource type. Потом нажмите Next.
  6. В поле Group укажите ту группу, которой Вы хотите, чтобы принадлежал ресурс MSMQ.
  7. На закладке возможных владельцев, добавьте те узлы, которые смогут обслуживать ресурс MSMQ.
  8. На странице зависимостей (Dependencies в Available resources) добавьте ресурс сетевого имени и физического диска.
  9. Нажмите Finish.
  10. В дереве кластерных групп нужно выбрать Resources, а затем в окне подробностей выделить ресурс MSMQ.
  11. В меню File, выберите Bring Online.
  12. В дереве кластерных групп нужно выбрать ту кластерную группу, которой должен принадлежит ресурс MSMQ. Нажать New, а затем щелкнуть Resource, чтобы запустился мастера создания нового ресурса.
  13. В текстовом поле Resource Name введите название: “Computer Management”.
  14. В списке Resource Type, выберите Generic Application, и затем нажмите Next.
  15. В поле Group укажите ту группу, которой принадлежит ресурс MSMQ.
  16. На закладке Possible Owners, выберите возможных владельцев и нажмите Next.
  17. На странице зависимостей добавьте ресурс сетевого имени и ресурс MSMQ, который Вы перед этим создавали. Нажмите Next.
  18. В командной строке введите: mmc compmgmt.msc
  19. В Current Directory введите: %windir%\system32
  20. Нужно выбрать Use Network Name для имени компьютера, и Allow application to interact with desktop. Нажмите Next, а затем Finish.
  21. В дереве кластерных групп нужно выбрать Resources, а затем в окне подробностей выделить ресурс Computer Management, который Вы только что создали.
  22. В меню File, выберите Bring Online.

Для управление виртуальным сервером, Вы должны подключиться к нулевой сессии, т.е. Console Session (Для подключения через RDP к Session 0 нужно запустить следующую команду: %systemroot%\system32\mstsc.exe /Admin). Также для управления очередями MSMQ в кластерной среде можно использовать утилиту MMCV.exe. Для получения более подробной информации об этой утилите ознакомьтесь со статьёй How to use the Mmcv.exe utility to manage clustered Message Queuing resources. Однако, мне чаще всего хватало тривиальной оснастки mmc, правда для подключения именно к виртуальной очереди MSMQ следует явно подключиться в Computer Management к виртуальному имени, от которого зависит кластерный ресурс MSMQ. После настройки MSMQ для работе в качестве виртуальной службы кластера, не забывайте дать необходимые права на саму виртуальную службу тем учётным записям пользователей, которые будут создавать очереди, а также раздать права к тем очередям, которые будут вами созданы.

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

Если необходимо, чтобы в случае административного или из-за отказа перемещения ресурсов MSMQ на другой узел, содержимое очереди не очищалось, создавайте очередь транзакционной и обрамляйте отправку сообщений транзакциями (в терминах Windows, а не MSSQL).

Полезные ссылки:

(на примере полки с 14 одинаковыми дисками)

Введение

В качестве утилиты для эталонного тестирования дисковой подсистемы используется разработанная Майкрософт программа SQLIO, подробное описание которой представлено в статье Эталонный тест дисковой подсистемы SQLIO. В методике используется ограниченный набор параметров вызова SQLIO. Давайте рассмотрим назначение параметров на примере: sqlio -kR -s300 -b64 -f1 -i2000000 -o1 -t1 -R1 -LP -a0xf –BN Параметр -k определяет, будет ли производиться чтение (R) или запись (W). Параметр -s задаёт продолжительность теста, указываемую в секундах. Параметр -b задаёт размер блока ввода-вывода в килобайтах.  Параметр -f определяет число блоков в строке. Параметр –i определяет число строк. С помощью параметров -b, -f и -i задаётся размер рабочей нагрузки, как это показано на рисунке 1.

image001

Рис.1.

Параметр -o указывает количество отправляемых в одном потоке запросов ввода-вывода, т.е. глубину очереди. Практика показывает, что программа SQLIO при глубине очереди 64 и выше может вести себя нестабильно, поэтому число 64 не превышалось. Параметр -t задаёт число используемых в тесте потоков, максимальное значение 256. В настоящей методике этот параметр не превышает числа ядер процессоров. Параметр -R задаёт номера LUN сырых (RAW) разделов дисков. Параметр –L задаёт таймер теста, в методике используется таймер процессоров. Параметр -a задаёт маску используемых в тесте процессоров. Параметр –B используется для отключения аппаратного и программного кэширования (кэш дисков и дисковых контроллеров будет отключён, если ими такая возможность поддерживается). В отчёте по каждому из единичных тестов, выполненных утилитой SQLIO, кроме численных параметров рабочей нагрузки данного теста указаны и вычисленные показатели производительности. Кроме метрик задержки, можно увидеть две величины: IOs/sec и MBs/sec. Первая является ни чем иным, как IOPS (Input-Output Operations Per Second), и показывает количество операций ввода-вывода в секунду, которые было обработано тестируемой дисковой подсистемой. Эта величина лучше всего характеризует производительность обслуживания коротких запросов, характерных для OLTP-нагрузки (8KB). Если приложение, для которого тестируется дисковая подсистема, использует в своей работе преимущественно такую нагрузку, может оказаться, что сравнения полученных в разных конфигурациях результатов стоит делать по этой метрике. Один диск на сегодняшний день может обслуживать от 50 IOs/sec для SATA и до 200 IOs/sec для FC дисков. Второй метрикой является производительность передачи данных, так называемый Traffic Throughput. Это основная метрика настоящей методики, поскольку большинству приложений баз данных характерны укрупнённые запросы (например, упреждающее чтение способно использовать запросы ввода-вывода в 64 и 128 КБ).

Этап №0. Подготовка

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

Этап №1. Калибровка дисков

Задача: На этом этапе мы должны убедиться, что используемые диски работоспособны, определить разброс скоростей чтения и записи по дискам, чтобы потом учитывать возможности каждого диска при распределении дисков в массивах. Возникает резонный вопрос, почему бы не воспользоваться стандартными в таких случаях стресс – тестами, которые, как правило, предоставляются вендором. Объяснение простое. Чаще всего мне доводилось работать с серверами удалённо, а в таких условиях не всегда удаётся добиться оперативной реакции обслуживающего аппаратную часть персонала. В таких случаях проще сделать быстрый тест на “вшивость”. К тому же, не всегда тесты охватывают сразу все уровни системы, они могут ограничится только дисками или тестировать контроллер вместе с дисками. Существуют также специализированные тесты, которые позволяют тестировать систему в целом и определять её пригодность к использованию для того – либо иного приложения. У Майкрософт, к слову, есть подобный стресс – тест, который позволяет протестировать дисковую систему и сервер. Называется эта утилита: SQLIOSim.

Read the rest of this entry »

 


Одной из распространённых задач систем с высокой транзакционной загрузкой является определение того, достаточно ли производительна подсистема ввода-вывода, обслуживающая журнал транзакций. Часто «узким местом» становиться дисковая подсистема, используемая в качестве долговременного носителя для файла журнала транзакций обслуживаемой SQL Server базы данных. Одним из важных параметров дисковой подсистемы является время доступа к данным на диске. Современным дисковым подсистемам характерно время доступа порядка 1 – 5 ms. Проверить, какое время доступа у используемой для размещения файла журнала транзакций дисковой подсистемы можно с помощью административного динамического представления: sys.dm_os_wait_stats (Transact-SQL). Данные в этом представлении накапливаются с момента последнего запуска службы SQL Server, поэтому, рекомендуется очистить эту статистику. Сделать это можно следующей командой:

    DBCC SQLPERF (‘sys.dm_os_wait_stats’, CLEAR);
    GO

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

    SELECT      (wait_time_ms – signal_wait_time_ms) / waiting_tasks_count AS [Время отклика долговременного носителя журнала (ms)]
                  ,    max_wait_time_ms AS [Максимальное время ожидания (ms)]
    FROM        sys.dm_os_wait_stats
    WHERE       wait_type = ‘WRITELOG’ AND waiting_tasks_count > 0;

Здесь:

     

  • wait_time_ms – общее время ожидания данного типа в миллисекундах. Это время включает в себя время signal_wait_time_ms.
  • signal_wait_time_ms – разница между временем сигнализации ожидающего потока и временем начала его выполнения.
  • waiting_tasks_count – число ожиданий данного типа. Этот счетчик наращивается каждый раз при начале ожидания.
  • max_wait_time_ms – максимальное время ожидания данного типа.

     

В публичном документе Майкрософт: «Diagnosing Transaction Log Performance Issues and Limits of the Log Manager» (автор: Mike Ruthruff) рекомендовано чтобы время отклика долговременного носителя журнала было в диапазоне от 1ms до 5ms.