Боремся с Deadlock на Net.Framework - не работает WSUS

После установки очередного обновления на сервере, который сам и является WSUS(Windows Software Update Service) сервером, и перезагрузки его не мог никак зайти в консоль WSUS - она постоянно выпадала, не помогало даже удаление файла wsus в папке %appdata%\Microsoft\MMC\.

Поиск по ошибке вида:

ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

а также в application логе:

Event Type: Warning
Event Source: W3SVC-WP
Event Category: None
Event ID: 2262
Date: 22.07.2011
Time: 10:49:40
User: N/A
Computer: WSUS-REAL
Description:
ISAPI 'C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Поиск в интернете всё время приводил к одной и той же статье:

http://support.microsoft.com/kb/974165/en-us
По которой не ясно было что делать, по крайней мере для меня.

Всё говорило о том что "съехала крыша" у Net.Framework, поскольку базу WSUS(SUSDB), расположенную на SQL кластере переводил в offline, а затем в online с отключением пользователей. Эти манипуляции с базой ни привели ни к чему.

На сервере были установлены следующие версии Net.Framework: 2.0, 3.0, 3.5 со всем обновлениями

Так как WSUS перестал работать после установки последних обновлений и перезагрузки, решил откатить последнее обновление, KB2478658 для Net.Framework 2.0 и 3.5 и через "Установка и Удаление Программ" исправил установку Net.Framework 3.5. После перезапуска Windows(на всякий случай) WSUS заработал нормально.

Кстати, после этого я установил обновление KB2478658 и перезагрузил контрольно сервер - WSUS всё-равно работал нормально, просто какой то глюк с Net.Framework.

Как смонтировать сетевой ресурс с Windows сервера в папку Linux

Пусть мы хотим смонтировать сетевой ресурс:

//backup/backup/SVN-02

В локальную папку на сервере

/home/backup

И при этом что бы эта папка автоматически монтировалась при загрузке.
Шаг 0.
проверяем, что в системе установлен пакет smbfs командой:

dpkg --get-selections | smbfs

если его нету устанавливаем из-под пользователя root:

apt-ger install smbfs

Шаг 1.

Для этих целей в домене создали учетную запись пользователя domuser с паролем password123
И предоставляем ей доступ к сетевому ресурсу //backup/backup/SVN-02
Шаг 2.

Создаем файл:

/etc/backup.cred

это можно сделать командой:

touch /etc/backup.cred

Файл должен быть следущего содержания:

username=domuser
password=password123

С символом Enter после последней введённой строки.
Отредактировать файл можно редактором nano командой:

nano /etc/backup.cred


Шаг 3.
Установка необходимых прав на файл /etc/backup.cred
выполняется командой:

chmod 600 /etc/backup.cred


права 600 - чтение и изменение только для владельца
права 644 - чтение и изменение только для владельца, чтение для всех остальных

Шаг 4.
Открываем на редактирование файл файловых систем монтируемых, при загрузке:

nano /etc/fstab


и в конце дописываем строки вида, где вместо пробелов символы табуляции:

//backup/Backup/SVN-02/home/backupcifscredentials=/etc/backup.cred,rw00

Вариант команды ручного монтирования1:

mount -t cifs //backup/backup/SVN-02/home/backup -o credentials=/etc/backup.cred,workgroup=corp.kaus.ru,wr


Вариант команды ручного монтирования2:

mount -t cifs //backup/backup/SVN-02 /home/backup -o credentials=/etc/backup.cred,wr


Оба варианта рабочих.
Здесь можно использовать в качестве адресов-источников монтирования:

//10.1.224.185/backup/SVN-02
или
//margarita/backup/SVN-02
или
//backup/backup/SVN-02 где backup это DNS-алиас


Шаг 5.
Проверяем смонтированные файловые системы командой:

mount

Содержимое смотнтированного каталога смотрим камандой:

ls -l /home/backup


Ссылки по теме:

http://www.cyberciti.biz/tips/how-to-mount-remote-windows-partition-windows-share-under-linux.html

http://www.opennet.ru/docs/RUS/mount/mount04.html

http://ubuntuforums.org/showthread.php?t=1292552

http://www.go2linux.org/wrong-fs-type-bad-option-bad-superblock

Замедление при копировани больших файлов - есть решения

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

При копировании больших файлов в среде WINDOWS (число файлов мало <15, а их суммарный объем в разы превышает объем оперативной памяти хоста куда происходит копирование) вот уже несколько лет наблюдаю следующую картину:

Например, копируем с того хоста куда идет копирование один 90Гб-й файл, т.е. диск куда сохраняются файлы при копировании расположен на той же машине - которая выполняет операции копирование файлов с удаленного хосте по сети. Сетевые интерфейсы при этом подняты со скоростью по 1Gb/s и ещё объединены в Teaming по 2 в основном по LACP в режиме Round Robin.

Машина куда сохраняются файлы некоторое время с большой скоростью принимает их, примерно до того момента, как создается ощущение, что пока не заполниться кэш оперативной памяти под дисковое копирование, а после этого начинается резкое замедление - поскольку этот самый "кэш" начинает сбрасывать данные на диск и резко замедляет скорость забора данных с сетевого источника, о чем свидетельствует наблюдение за сетевой нагрузкой (Windows Task Manager->Networking).


На рисунке приведено поведение при использовании eseutil.exe

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

Иногда есть возможность отключить кэширование записи на диск, делается это в "Диспетчере устройств"(devmgmt.msc)->"Дисковые устройства"->свойства диска->вкладка "Политика":



но у некоторых подключенных дисковых устройств (у самого нужного сервера) такой возможности нету, например СХД EMC CLARiiON CX4-120:



а у некоторых есть, например HP EVA4000:




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

Фактически нужно только два файла eseutil.exe и ese.dll

синтаксис команды:

eseutil.exe /y {source-file} /d {destination-file}


В моем случае упирались в производительность дисковой подсистемы



, а средствами винды вообще не могли нормально скопировать только теряли время - несколько часов, были ошибки вида:

на Win2003:
"Cannot copy Insufficient system resources exist to complete the requested service."


на Win2008:
"An unexpected error is keeping you from copying the file. If you continue to receive this error, you can use the error code to search for help with this problem. Error 0x8007046A:Not enough server storage is available to proceed this command"


После использования eseutil, смогли начать копирование. Индикация процесса копирования происходит так же, как при дефрагментации баз:



Ощющение что с ней происходит всё быстрее и надежнее не покидало. Скорее всего это происходит из-за того что eseutil принудительно сбрасывает "кэш" копирования на диск по каким-то условиям.

Но и в этом случае eseutil не помогла...
Иногда никак не получается скопировать, так eseutil где-то на 95-98% копирования может выдать ошибку вида:

FAILURE: GetOverlappedResult (read): Not enough server storage is available to process this command.

где-нибудь в конце 90Гбайтного файла.

Тогда есть вариант поделить файл (WinRAR, 7zip, GNU SPLIT) и копировать по частям, а потом эти части собрать (copy, 7zip).

Когда ничего не помогает - как было в моем случае - заливаем бэкап на другой диск и форматим сбойный.

Есть ещё варианты с поднятием ftp-сервера на источнике и докачкой на приемнике. в общем случае - это через другие - протоколы - не SMB: fpt, p2p(torrent например)

либо пользоваться утилитами, позволяющими прерывать копирование по сети (SMB) и продолжать с места остановки, например "CopyFile 2", KillCopy, Real Total Copy и т.п.

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

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

ссылки по теме:

http://blogs.technet.com/b/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx

http://support.microsoft.com/kb/198386/

http://support.microsoft.com/kb/106167

http://support.microsoft.com/kb/332023/ru

Переключение аппаратно зеркалируемого диска сервера на пассивное плечо

Переключение аппаратно зеркалируемого диска сервера на пассивное плечо.
Аппаратное зеркало на CLARiiON CX4-120.

Условия:
Есть сервер Windows (EMC PowerPath + Navisphere Agent установлены, естественно), которому через SAN поданы диски одинаковой емкости, и настроена аппаратная синхронизация между ними (на дисковых массивах). т.е. на обной системе хранения есть активный LUN, и на другой тоже есть LUN, но пассивный, и происходит непрерывная репликация данных между ними.

Задача:
Переключиться на пассивный диск другой системы хранения.



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

Заходим в Navisphere Manager и делаем Promote на Secondary Image LUN-е:



в итоге получаем:



и нужно сделать на нем "Reactivate Disk".

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

Отключение проверки DNS на машине под управлением Windows

текст для создания reg-файла:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"DisableStrictNameChecking"=dword:00000001