Создание частной очереди MSMQ в кластере Microsoft с помощью скрипта

Мы переходим на Windows 2008 R2 Standard и будем использовать конфигурацию Microsoft Clustering (активный-пассивный). Наше приложение сильно зависит от частных очередей MSMQ, и наша установка создает более 100 частных очередей с использованием следующего кода C#.

MessageQueue.Create(".\private$\myqueue", false);

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

Затем мы попытались изменить код на:

MessageQueue.Create("ИМЯ КЛАСТЕРА\private$\myqueue", false);

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

У меня два вопроса: 1) Есть ли способ запустить установку в контексте кластера, чтобы при создании частной очереди она фактически создавала очередь в кластере?

2) Если нет, то как лучше всего создавать очереди в кластере через .NET? Я читал некоторые блоги, в которых люди создают службу Windows-посредника, которая находится внутри кластера, а затем их установка использует межпроцессное взаимодействие, чтобы сообщить службе, какие очереди создавать. Это похоже на взлом, но выполнимо, если это окажется единственным подходом.


cluster-computing msmq windows-server-2008-r2
person Dogbert581    schedule 10.11.2010    source источник
comment
Пожалуйста, отмечайте внимательнее. Удаление неправильного тега cluster-analysis (иначе: кластеризация, в отличие от кластерных вычислений)   -  person Has QUIT--Anony-Mousse    schedule 08.06.2012

Ответы (4)


arrow_upward
3
arrow_downward

Вот как это сделать вручную на кластеризованном экземпляре. (не через код)

ТОЛЬКО НА АКТИВНОМ УЗЛЕ Создайте необходимые очереди MSMQ.

а. Нажмите «Пуск», щелкните правой кнопкой мыши командную строку и выберите «Запуск от имени администратора».

б. В командной строке введите следующие команды (где {virtualname} — это имя экземпляра.)

    i.  SET _CLUSTER_NETWORK_HOSTNAME_={virtualname}

   ii.  SET _CLUSTER_NETWORK_NAME_={virtualname}

  iii.  Compmgmt.msc

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

д. Разверните Службы и приложения.

е. Разверните очередь сообщений.

ф. Щелкните правой кнопкой мыши Частные очереди и выберите Создать, Частная очередь.

г. Убедитесь, что Create in: является виртуальным именем.

час В поле Имя очереди: private$\ введите имя очереди и нажмите кнопку ОК.

я. Закройте Управление компьютером.

Это работало на Windows 2008 R2

person HunterGatherer    schedule 27.10.2011

arrow_upward
3
arrow_downward

То же решение Из Powershell (что вы еще не используете ???) Я некоторое время работал над этой проблемой, недавно нашел эту тему.

http://winterdom.com/2011/10/using-powershell-with-clustered-msmq

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

Invoke-Command -ScriptBlock {
$env:_CLUSTER_NETWORK_NAME_ = 'myclusterMSMQ'

Write-Host "... load the .NET Messaging assembly"
[Reflection.Assembly]::LoadWithPartialName("System.Messaging")
$environment="perf2"
$groups=@{`
    "MessageRouters"="DomainName\Group";`
    "CalcDaemons"="DomainName\GroupB";`
    "MessageSenders"="DomainName\GroupC";`
}


function new-queue ([string] $queuepath,[bool] $transactional)
{
    if (([System.Messaging.MessageQueue]::Exists($queuepath))){throw "$queuepath already exists"}
    Write-Host "creating $queuepath"
    [System.Messaging.MessageQueue]::Create($queuepath,$transactional)
}

function set-msmqpermission ([string] $queuepath,[string] $account, [string] $accessright)
{
    if (!([System.Messaging.MessageQueue]::Exists($queuepath))){
        throw "$queuepath could not be found."
    }
    $q=New-Object System.Messaging.MessageQueue($queuepath)
    $q.SetPermissions($account,[System.Messaging.MessageQueueAccessRights]::$accessright,            
      [System.Messaging.AccessControlEntryType]::Set)
}

#example usage
new-queue ".\private$\$($environment)ack" $false
set-msmqpermission ".\private$\$($environment)ack" $groups.messagerouters "FullControl"

} -ComputerName "servername (or array)"
person JorgeSandoval    schedule 29.06.2012
comment
Слегка измененная версия работает с 2019, New-MSMQQueue и другими командлетами, поэтому вам не нужно прибегать к ним. Вы можете использовать их с именем кластера, которое вам просто нужно установить 2 переменные среды - замените $clusterName на то, чем является ваш кластер, тогда все командлеты должны работать нормально $env:computername = $clusterName $env:_CLUSTER_NETWORK_NAME_=$clusterName - person Bill Dinger; 17.11.2019

arrow_upward
0
arrow_downward

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

SET _CLUSTER_NETWORK_HOSTNAME_=cluster_name
SET _CLUSTER_NETWORK_NAME_=cluster_name

Он работал на Windows Server 2003 R2.

person ra_sk    schedule 13.05.2011

arrow_upward
0
arrow_downward

Ради бедных душ (таких как я), которые часами искали, как добиться этого с помощью .NET MessageQueue, можно создавать очереди на кластеризованном MSMQ без PowerShell:

Environment.SetEnvironmentVariable("_CLUSTER_NETWORK_HOSTNAME_", "yourclustername", EnvironmentVariableTarget.User);
Environment.SetEnvironmentVariable("_CLUSTER_NETWORK_NAME_", "yourclustername", EnvironmentVariableTarget.User);

var path = @"yourclustername\Private$\yourprivatequeuepath";
MessageQueue.Create(path, false);

Проверено на сервере 2012.

ПРЕДУПРЕЖДЕНИЕ. Будьте осторожны при настройке переменных среды, так как их может быть трудно очистить впоследствии, ДАЖЕ, если вы установите их с помощью EnvironmentVariableTarget.User. Кроме того, кажется, что устанавливать переменные среды необходимо только в том случае, если вы пытаетесь получить доступ к частной очереди в кластере с компьютера, внутри em> кластер.

Если вы случайно установили переменные среды, вы можете очистить их в реестре в HKCU\Environment. Одна из проблем, которая может возникнуть, заключается в том, что вы запустили код в другом пользовательском контексте, в котором установлены переменные среды. В одном случае я смог войти в систему как этот пользователь, а затем удалить его из реестра, но в другом случае я отлаживал веб-сайт под IIS, и они были установлены в учетной записи LOCALSYSTEM. Чтобы очистить их, я опубликовал веб-сайт, на котором значения были равны нулю. Вы также хотите проверить значения переменных env для .User, .Process и .Machine. Обратите внимание, что изменения в области .Process не вступают в силу до тех пор, пока компьютер не будет перезапущен, если речь идет о процессе LOCALSYSTEM.

person Daniel    schedule 14.04.2016