Не удалось смонтировать ресурс Windows, программа вызвала разрыв соединения

Обновлено: 06.07.2024

Сбой подключения файловой системы к инстансу Amazon EC2 в Microsoft Windows.

Действие

Не используйте Amazon EFS с инстансами Windows EC2, которые не поддерживаются.

Доступ запрещен сервером

Сбой монтирования файловой системы со следующим сообщением:

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

Действие

Если вы пытаетесь смонтировать файловую систему с помощью IAM, убедитесь, что вы используете параметр -o iam в команде монтирования. Это говорит помощнику монтирования EFS передать ваши учетные данные цели монтирования EFS. Если у вас по-прежнему нет доступа, проверьте политику вашей файловой системы и политику идентификации, чтобы убедиться, что к вашему соединению не применяются положения DENY, и что к соединению применяется хотя бы одно предложение ALLOW. Дополнительные сведения см. в разделах Использование IAM для управления доступом к данным файловой системы и Создание политик файловой системы.

Сбой автоматического монтирования, и экземпляр не отвечает

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

Действие

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

Сбой монтирования нескольких файловых систем Amazon EFS в /etc/fstab

Для экземпляров, использующих систему инициализации systemd с двумя или более записями Amazon EFS в /etc/fstab, могут быть случаи, когда некоторые или все эти записи не монтируются. В этом случае вывод dmesg показывает одну или несколько строк, подобных приведенным ниже.

Действие

В этом случае мы рекомендуем вам создать новый файл службы systemd в /etc/systemd/system/mount-nfs-sequentially.service со следующим содержимым.

После этого выполните следующие две команды:

sudo systemctl daemon-reload

sudo systemctl включает mount-nfs-sequentially.service

Затем перезапустите инстанс Amazon EC2. Файловые системы монтируются по требованию, обычно в течение секунды.

Сбой команды монтирования с сообщением об ошибке "неправильный тип файловой системы"

Выполнение команды mount завершается со следующим сообщением об ошибке.

Действие

Если вы получили это сообщение, установите пакет nfs-utils (или nfs-common в Ubuntu). Дополнительные сведения см. в разделе Установка клиента NFS.

Сбой команды монтирования с сообщением об ошибке "неправильный параметр монтирования"

Выполнение команды mount завершается со следующим сообщением об ошибке.

Действие

Это сообщение об ошибке, скорее всего, означает, что ваш дистрибутив Linux не поддерживает версии сетевой файловой системы 4.0 и 4.1 (NFSv4). Чтобы убедиться, что это так, вы можете запустить следующую команду.

Сбой монтирования файловой системы сразу после создания файловой системы

После создания целевого объекта подключения для полного распространения записей службы доменных имен (DNS) в регионе AWS может потребоваться до 90 секунд.

Действие

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

Подключение файловой системы зависает, а затем завершается с ошибкой тайм-аута

Команда монтирования файловой системы зависает на минуту или две, а затем завершается с ошибкой тайм-аута. В следующем коде показан пример.

Действие

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

< бр />

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

Сбой монтирования файловой системы с использованием DNS-имени

Сбой монтирования файловой системы, использующей DNS-имя. В следующем коде показан пример.

Действие

Проверьте конфигурацию VPC. Если вы используете собственное VPC, убедитесь, что настройки DNS включены. Дополнительную информацию см. в разделе «Использование DNS с вашим VPC» в Руководстве пользователя Amazon VPC. Кроме того, файловая система и целевые DNS-имена монтирования не могут быть разрешены из-за пределов VPC, где они существуют.

Чтобы указать DNS-имя в команде mount, необходимо сделать следующее:

Убедитесь, что цель подключения Amazon EFS находится в той же зоне доступности, что и инстанс Amazon EC2.

Убедитесь, что цель подключения находится в том же облаке VPC, что и инстанс Amazon EC2.В противном случае вы не сможете использовать разрешение DNS-имен для целей подключения EFS, которые находятся в другом VPC. Дополнительные сведения см. в разделе Подключение файловых систем EFS из другого аккаунта AWS или VPC.

Подключите свой инстанс Amazon EC2 к Amazon VPC, настроенному на использование DNS-сервера, предоставленного Amazon. Дополнительную информацию см. в разделе Наборы параметров DHCP в Руководстве пользователя Amazon VPC.

Убедитесь, что в Amazon VPC подключаемого инстанса Amazon EC2 включены имена хостов DNS. Дополнительную информацию см. в разделе «Обновление поддержки DNS для вашего VPC» в Руководстве пользователя Amazon VPC.

Сбой монтирования файловой системы с сообщением «nfs не отвечает»

Сбой монтирования файловой системы Amazon EFS при переподключении протокола управления передачей (TCP) с сообщением «nfs: имя_сервера по-прежнему не отвечает».

Действие

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

Состояние целевого жизненного цикла монтирования зависло

Состояние жизненного цикла цели подключения зависло в состоянии создания или удаления.

Действие

Повторите вызов CreateMountTarget или DeleteMountTarget.

Крепление не отвечает

Подключение Amazon EFS не отвечает. Например, такие команды, как ls, зависают.

Действие

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

Чтобы решить эту проблему, убедитесь, что другое приложение записывает файлы в хранилище Amazon EFS и находится в состоянии непрерывного сна ( D ), как показано в следующем примере:

После того, как вы убедились, что это так, вы можете решить проблему, дождавшись завершения другой операции записи или применив обходной путь. В примере с ls вы можете использовать команду /bin/ls напрямую, а не псевдоним. Это позволяет продолжить выполнение команды, не зависая в записываемом файле. В общем, если приложение, записывающее данные, может периодически принудительно сбрасывать данные, возможно, с помощью fsync(2), это может помочь улучшить реакцию вашей файловой системы на другие приложения. Однако это улучшение может быть достигнуто за счет производительности, когда приложение записывает данные.

Операции с недавно смонтированной файловой системой возвращают ошибку «плохой дескриптор файла»

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

Эта ошибка может возникнуть, если экземпляр Amazon EC2 был подключен к одной файловой системе и одной цели подключения с указанным IP-адресом, а затем эта файловая система и цель подключения были удалены. Эта проблема может возникнуть, если вы создаете новую файловую систему и монтируете цель для подключения к этому инстансу Amazon EC2 с тем же целевым IP-адресом.

Действие

Вы можете устранить эту ошибку, размонтировав файловую систему, а затем повторно смонтировав файловую систему в экземпляре Amazon EC2. Дополнительные сведения об отключении файловой системы Amazon EFS см. в разделе Размонтирование файловых систем.

Не удалось размонтировать файловую систему

Если ваша файловая система занята, вы не сможете размонтировать ее.

Действие

Вы можете решить эту проблему следующими способами:

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

Дождитесь завершения всех операций чтения и записи, а затем повторите попытку команды umount.

Принудительное размонтирование с помощью команды umount -f.

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

После установки обновления безопасности на сервер, на котором работает Microsoft Exchange Server, либо Outlook в Интернете (OWA), либо панель управления Exchange (ECP), либо оба приложения перестают работать на сервере.

OWA отображает следующее сообщение об ошибке:

ECP отображает следующее сообщение об ошибке:

Причина

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

Разрешение

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

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

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

Если сообщение об ошибке ECP продолжает отображаться, выполните следующие действия:

Запустите диспетчер IIS на сервере.

Перейдите на веб-сайт Exchange Backend > Виртуальный каталог ECP.

Выберите Настройки приложения > BinsearchFolder.

Проверьте пути к перечисленным каталогам Exchange. Вы можете увидеть пути к каталогам, похожие на следующие:

Замените пути следующими путями:

C:\Program Files\Microsoft\Exchange Server\V15\bin;
C:\Program Files\Microsoft\Exchange Server\V15\bin\CmdletExtensionAgents;
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\bin

Примечание. Пути должны указывать на место, где установлен Exchange Server. В следующих примерах предполагается, что программа установлена на диске C и используется версия Microsoft Exchange Server 2013. Если она установлена на другом диске вашего сервера или вы используете другую версию, например Microsoft Exchange Server 2010, затем используйте информацию о пути и версии, подходящую для вашей установки.

Перейдите к папке, содержащей сценарии Exchange Server. По умолчанию сценарии находятся по следующему пути для Exchange Server 2013:

Примечание. Для Exchange Server 2010 сценарии будут находиться в папке V14.

Запустите Exchange Management Shell от имени администратора и выполните следующие сценарии: .\UpdateCas.ps1 и .\UpdateConfigFiles.ps1 .

Выйдите из командной консоли Exchange и откройте окно командной строки от имени администратора.

Перезапустите сервер и убедитесь, что при доступе к ECP больше не появляется сообщение об ошибке.

В этой статье представлено решение проблемы, из-за которой резервное копирование Microsoft Windows Server завершается с ошибкой: сбой операции службы теневого копирования тома.

Применимо к: Windows Server 2012 R2, Windows Server 2016
Исходный номер базы знаний: 2615182

Симптомы

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

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

В журнале событий приложения будет записано следующее сообщение об ошибке:

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

Ошибки будут похожи на следующие:

Причина

Когда резервная копия Windows Server пытается выполнить резервное копирование тома диска, для этого тома создается моментальный снимок теневого копирования тома. При создании моментального снимка вызывается любой модуль записи службы теневого копирования томов (VSS), связанный с томом. Если какой-либо из модулей записи VSS обнаружит ошибку, все задание резервного копирования завершится ошибкой. В этом примере модуль записи VSS SQL обнаруживает ошибку, которая приводит к сбою задания резервного копирования.

Разрешение

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

В этом примере экземпляр SQL Server с именем SBSMONITORING не может создать моментальный снимок.

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

В этом примере возникла проблема с базой данных SBSMonitoring.

После того как вы определили экземпляр SQL Server, в котором возникла проблема, первым шагом будет проверка резервного копирования с остановленным экземпляром SQL Server.В нашем примере с экземпляром SSBMonitoring вы должны остановить службу SQL Server (SBSMonitoring) на сервере.

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

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

При установке Small Business Server 2008 по умолчанию необходимо остановить следующие службы:

SQL Server (SSMonitoring)
Внутренняя база данных Windows

При установке Small Business Server 2011 Standard по умолчанию необходимо остановить следующие службы:

В этом разделе содержится информация о следующих проблемах:

Основные действия по устранению неполадок.

Восстановление после сбоя отказоустойчивого кластера.

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

Использование расширенных хранимых процедур и COM-объектов.

Основные шаги по устранению неполадок

Первый шаг диагностики – запустить новую проверку кластера. Дополнительные сведения о проверке см. в разделе Создание отказоустойчивого кластера: проверка конфигурации. Это может быть выполнено без перерыва в обслуживании, поскольку это не влияет на какие-либо онлайн-ресурсы кластера. Проверка может быть запущена в любое время после установки функции отказоустойчивой кластеризации, в том числе до развертывания кластера, во время создания кластера и во время его работы. Фактически, когда кластер используется, выполняются дополнительные тесты, которые проверяют, соблюдаются ли передовые методы для высокодоступных рабочих нагрузок. Из этих десятков тестов только некоторые из них повлияют на выполнение рабочих нагрузок кластера, и все они относятся к категории хранилища, поэтому пропустить всю эту категорию — это простой способ избежать подрывных тестов.
Отказоустойчивая кластеризация поставляется со встроенной защитой для предотвращения случайного простоя при выполнении тестов хранилища во время проверки. Если в кластере есть какие-либо онлайн-группы при инициации проверки, а тесты хранилища остаются выбранными, он предложит пользователю подтвердить, хотят ли они запустить все тесты (и вызвать простои) или пропустить тестирование дисков любых онлайн-групп. во избежание простоев. Если вся категория хранилища была исключена из тестирования, то этот запрос не отображается. Это обеспечит проверку кластера без простоев.

Как повторно проверить кластер

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

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

Оставаясь на странице "Сводка", нажмите "Просмотреть отчет", чтобы просмотреть результаты теста.

Чтобы просмотреть результаты тестов после закрытия мастера, см. %SystemRoot%\Cluster\Reports\Validation Report date and time.html, где %SystemRoot% – это папка, в которой установлена операционная система (например, C:\Windows).

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

Чтобы просмотреть разделы справки о проверке кластера после закрытия мастера, в оснастке отказоустойчивого кластера нажмите «Справка», выберите «Разделы справки», перейдите на вкладку «Содержание», разверните содержимое справки по отказоустойчивому кластеру и нажмите «Проверка отказоустойчивого кластера». Конфигурация кластера. После завершения работы мастера проверки итоговый отчет отобразит результаты. Все тесты должны пройти либо с зеленой галочкой, либо, в некоторых случаях, с желтым треугольником (предупреждение). При поиске проблемных областей (красные крестики или желтые знаки вопроса) в той части отчета, где обобщаются результаты теста, щелкните отдельный тест, чтобы просмотреть подробности. Любые проблемы с красным крестиком необходимо устранить до устранения неполадок SQL Server.

Установить обновления

Установка обновлений — важная часть предотвращения проблем с вашей системой. Полезные ссылки:

Восстановление после сбоя отказоустойчивого кластера

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

Аппаратный сбой в одном узле двухузлового кластера. Этот аппаратный сбой может быть вызван сбоем карты SCSI или операционной системы.

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

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

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

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

Решение общих проблем

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

Проблема: неправильное использование синтаксиса командной строки для установки SQL Server

Проблема 1. Сложно диагностировать проблемы установки при использовании параметра /qn из командной строки, так как параметр /qn подавляет все диалоговые окна программы установки и сообщения об ошибках. Если указан параметр /qn, все сообщения программы установки, включая сообщения об ошибках, записываются в файлы журнала установки. Дополнительные сведения о файлах журнала см. в разделе Просмотр и чтение файлов журнала установки SQL Server.

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

Проблема: SQL Server не может войти в сеть после миграции на другой узел

Проблема 1. Учетные записи службы SQL Server не могут связаться с контроллером домена.

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

Проблема 2. Пароли учетных записей службы SQL Server не идентичны на всех узлах кластера или узел не перезапускает службу SQL Server, перенесенную с отказавшего узла.

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

Проблема: SQL Server не может получить доступ к дискам кластера

Проблема 1. Прошивка или драйверы обновлены не на всех узлах.

Решение 1. Убедитесь, что все узлы используют правильные версии прошивки и одинаковые версии драйверов.

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

Решение 2. Буквы дисков для дисков кластера должны совпадать на обоих серверах. Если это не так, проверьте исходную установку операционной системы и службы кластеров Microsoft (MSCS).

Проблема: сбой службы SQL Server вызывает отработку отказа

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

Снимите флажок "Влиять на группу" на вкладке "Дополнительно" диалогового окна "Свойства полнотекстового текста". Однако если SQL Server вызывает отработку отказа, служба полнотекстового поиска перезапускается.

Проблема: SQL Server не запускается автоматически

Решение. Используйте Cluster Administrator в MSCS для автоматического запуска отказоустойчивого кластера. Служба SQL Server должна запускаться вручную; Администратор кластера должен быть настроен в MSCS для запуска службы SQL Server. Дополнительные сведения см. в разделе Управление службами.

Проблема: сетевое имя отключено, и вы не можете подключиться к SQL Server с помощью TCP/IP

Проблема 1: DNS дает сбой, когда ресурс кластера настроен на использование DNS.

Решение 1. Исправьте проблемы с DNS.

Проблема 2: повторяющееся имя в сети.

Решение 2. Используйте NBTSTAT, чтобы найти повторяющееся имя, а затем устранить проблему.

Проблема 3: SQL Server не подключается с помощью именованных каналов.

Решение 3. Чтобы подключиться с помощью именованных каналов, создайте псевдоним с помощью диспетчера конфигурации SQL Server для подключения к соответствующему компьютеру. Например, если у вас есть кластер с двумя узлами (узел A и узел B) и экземпляр отказоустойчивого кластера (Virtsql) с экземпляром по умолчанию, вы можете подключиться к серверу с отключенным ресурсом сетевого имени, выполнив следующие действия:

Определите, на каком узле работает группа, содержащая экземпляр SQL Server, с помощью администратора кластера. В данном примере это узел A.

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

Запустите диспетчер конфигурации SQL Server SQL Server на узле A. Просмотрите имя канала, который прослушивает сервер. Он должен быть похож на \\.\$$\VIRTSQL\pipe\sql\query.

На клиентском компьютере запустите диспетчер конфигурации SQL Server.

Создайте псевдоним SQLTEST1 для подключения через именованные каналы к этому имени канала. Для этого введите Node A в качестве имени сервера и измените имя канала на \\.\pipe\$$\VIRTSQL\sql\query.

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

Проблема: программа установки SQL Server завершается сбоем в кластере с ошибкой 11001

Проблема: потерянный раздел реестра в [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.X\Cluster]

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

Проблема: Ошибка настройки кластера: «У установщика недостаточно прав для доступа к этому каталогу: \Microsoft SQL Server. Установка не может быть продолжена. Войдите в систему как администратор или обратитесь к системному администратору»

Проблема: эта ошибка вызвана тем, что общий диск SCSI не разбит на разделы должным образом.

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

Удалите дисковый ресурс из кластера.

Удалить все разделы на диске.

Убедитесь в свойствах диска, что диск является базовым.

Создайте один раздел на общем диске, отформатируйте диск и назначьте ему букву диска.

Добавьте диск в кластер с помощью администратора кластера (cluadmin).

Запустите программу установки SQL Server.

Проблема: приложениям не удается задействовать ресурсы SQL Server в распределенной транзакции

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

Решение. Чтобы предотвратить такие проблемы, необходимо полностью включить службы MS DTC на серверах, где установлен SQL Server и настроен MS DTC.

Чтобы полностью включить MS DTC, выполните следующие действия:

В Панели управления откройте "Администрирование", а затем откройте "Управление компьютером".

На левой панели управления компьютером разверните Службы и приложения и нажмите Службы.

На правой панели управления компьютером щелкните правой кнопкой мыши Координатор распределенных транзакций и выберите Свойства.

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

В окне координатора распределенных транзакций перейдите на вкладку «Вход в систему» и задайте учетную запись для входа NT AUTHORITY\NetworkService.

Нажмите «Применить» и «ОК», чтобы закрыть окно координатора распределенных транзакций. Закройте окно «Управление компьютером». Закройте окно инструментов администрирования.

Использование расширенных хранимых процедур и COM-объектов

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

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

Читайте также: