MOSS2007 - Перемещение баз данных контента между экземплярами SQL Server с помощью центра администрирования

1. На странице "Управление приложениями" центра администрирования перейдите к разделу Управление веб-приложениями SharePoin и щелкните элемент Базы данных содержимого.

2. На странице "Управление базами данных контента" щелкните перемещаемую базу данных контента.

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





3. На странице "Управление параметрами базы данных содержимого" в разделе Удалить базу данных содержимого установите флажок Удалить базу данных содержимого , а затем нажмите ОК.

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

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

5. Откройте экземпляр источника SQL Server в программе SQL Server 2005 Management Studio, а затем разверните узел Базы данных.

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

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

7. В проводнике Windows перейдите к папке, где расположены файлы MDF и LDF для баз данных контента.

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

9. В программе SQL Server 2005 Management Studio откройте экземпляр источника SQL Server.

10. Правой кнопкой мыши щелкните узел Базы данных, перейдите к элементу Задачи, а затем щелкните элемент Присоединить.

11. В диалоговом окне Присоединение базы данных перейдите к папке, в которую были перемещены файлы MDF и LDF, выберите файл MDF для присоединяемой базы данных и нажмите OK.

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

13. На странице "Управление приложениями" в разделе Управление веб-приложениями SharePoint щелкните пункт Базы данных содержимого.

14. На странице "Управление базами данных контента" щелкните Добавить базу данных содержимого.

15. На странице "Добавление базы данных содержимого" убедитесь в том, что в меню Веб-приложение отображается верное веб-приложение.

16. Введите точное имя перемещенной базы данных контента в поле Имя базы данных и нажмите OK.

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

18. Выполните полный обход всех перемещенных баз данных контента. Дополнительные сведения о запуске полного обхода см. в разделе Запуск полного обхода содержимого (Office SharePoint Server 2007).

Источник - http://technet.microsoft.com/ru-ru/library/cc262792.aspx

MOSS2007 - Не запускается служба «Поиск в Windows SharePoint Services»

Описание проблемы:

При установке и настройки портала в Microsoft Office SharePoint Server 2007 возникала устойчивая ошибка - при попытке запустить службу "Поиск в Windows SharePoint Services" (в узле администрирования Операции – Службы на сервере) возникала ошибка «Этот сервер не индексирует данное приложение поиска». Все остальные службы запустились успешно.
В event viewer появляются ошибки, в частности:
Event id 6482
«Сбой задания администрирования сервера приложений для экземпляра службы Microsoft.Office.Server.Search.Administration.SearchServiceInstance (396b7812-2f44-4e56-8183-56c0c05620a8). Причина: Путь имеет недопустимую форму.
Сведения о технической поддержке:
System.ArgumentException: Путь имеет недопустимую форму.
в Microsoft.Office.Server.Search.Administration.SearchApi.RunOnServer[T](CodeToRun`1 remoteCode, CodeToRun`1 localCode, Boolean useCurrentSecurityContext, Int32 versionIn)
в Microsoft.Office.Server.Search.Administration.SearchApi.AddApp(Role role) в Microsoft.Office.Server.Search.Administration.SearchServiceInstance.InstallGathererApplicationIf()
в Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
в Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionL»
и
Event ID 10033
«Этот сервер не индексирует данное приложение поиска (назначено средство индексирования "moss.XXX.XX").
Контекст: приложение: c60f53a0-fad8-4ea9-b00f-9579305ebff2
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.»

Что имелось из окружения -
При запуске службы поиска я указывал доменные учетные записи для службы и для доступа к содержимому. Эти учетные записи прописаны в группе «администраторы». Сервер баз данных указывал как FQDN, проверку подлинности - Windows.
ОС – Windows Server 2003 enterprise R2, 32-bit, SP2, English. Последние заплатки установлены. Антивирус – Forefront Client Security.
SQL2005 c SP2, установлен на той же машине, что и MOSS2007, English
MOSS2007 c SP2, Russian (также установлен SP2 для WSS – это требование установки SP2 для MOSS).

Решение проблемы:

Оказалось до обидного простым. При начальном конфигурировании фермы через мастера и при запуске службы поиска следует указывать не FQDN а короткое NetBIOS имя сервера баз данных (hostname a не hostname.domain.com). После внесения этих изменений служба успешно стартовала и ферма перешла в состояние штатного функционирования, в Центре администрирования пропало предупреждение о необходимости закончить конфигурирование платформы.

EMC AVAMAR - система резервного копирования с глобальной дедупликацией на стороне клиента

Ниже приведены заметки о системе распределенного резервного копирования с дедупликацией данных на стороне клиентов EMC Avamar.

Avamar поставляется в 3 видах - как ПО, как устройство (сервер и ПО) и как виртуальная машина.

Устройства (appliance) поставляются в виде сервера, дистрибутива ОС (оптимизированный RedHat) и комплекта дистрибутива Avamar, которые интегратор должен самостоятельно поставить на этот сервер.

Устройство (appliance) 1 ТБ укомплектовано 6 дисками SAS, находящимися в RAID 5.
Устройство (appliance) 2 ТБ укомплектовано 6 дисками SATA, находящимися в RAID 10.
Доукомплектовать устройства дисками невозможно, если закуплено устройство в 1 ТБ и понадобится расширить емкость, придется закупать новое устройство. При этом объединить в RAIN архитектуру устройства разного объема невозможно.
В архитектуре RAIN есть роли storage node и utility node. Utility node не хранит информации, в нем 2 диска в RAID 1.

ПО можно ставить только на довольно узкий список поддерживаемых серверов. Для Avamar 4.X cейчас поддерживаются:
Dell PowerEdge 2950III, HP DL320s, HP DL360 G5 c MSA 60, HP DL365 с MSA60, HP DL380 G5, HP DL385 G2, IBM x3650.
Процессоры поддерживаются только 64-bit.

AVE - Avamar Virtual Engine версия 1,2 Требует 64-битного процессора.
AVD - виртуальная машина для демонстрации, позволяет сохранить около 10 ГБ - дедуплицированных данных. Запускается на VMWare workstation, требует 1 ГБ оперативной памяти. Работает на 32-битных процессорах.

Виртуальная машина с Avamar может быть 0,5 - 1 - 2 ТБ. Требует соответственно 3 - 4 - 16 ГБ RAM.
Процессор строго 64-бит .

Avamar проверяет сохраненные данные в фоновом режиме после окончания плановых резервных сессий резервного копирования. При этом некоторые служебные процессы (garbage collection) не должны пересекаться с сессиями резервного копирования во времени.

Дедупликация происходит на клиенте. Алгоритм работы ПО на клиенте следующий.

1. При помощи алгоритма Sticky-byte Factoring (вычисление бегущего хэша в 32 бита) выделяются сегменты из сохраняемых данных. Размер сегментов - от одного байта до 64 КБ.
2. Сжатие сегментов
3. Вычисление хэша SHA-1 (20 байт) для каждого сжатого сегмента и файлов целиком.
4. Commonality Factoring - запрос сервера Avamar на наличие в нем уникального сегмента.
5. Передача уникальных сегментов и метаданных на сервер Avamar.


На клиенте содержатся 2 файла с кэшем хэшей -
f_cahe.dat - содержит хэши файлов и метаданные
p_cache.dat - хэши фрагментов, отправленных на сервер

Рекомендуют устанавливать размер файлов f_cahe.dat в 1/8 от объема RAM а p_cache.dat 1/16 от объема RAM. При резервном копировании эти файлы выгружаются в RAM.

Root hash - хэш файла, его уникальный идентификатор.

Скорость работы клиентского приложения - сканирование примерно 1 млн объектов в час. Скорость резервного копирования - около 100 ГБ/час. Восстановление проходит дольше - около 25 ГБ в час (до 40 ГБ в час). Сильно зависит от типа данных.

После первичной дедупликации отсекается около 30 % данных. Для оценки первичной дедупликации есть вспомогательное ПО - avasst.exe Это набор скриптов, которые запускают клиента avamar и подсчитывают процент уникальных сегментов.

Если данные забьют хранилище сервера, он перейдет в режим Read Only. После этого требуется вручную запускать процесс очистки (garbage collection).

При резервном копировании данных файловой системы 15 рабочих станций, (копировали все кроме программ и windows) дедупликация получилась 1:20 (на 300 ГБ хранились 5,7 ТБ полезных данных).

На 1 узел максимально возможно 18 одновременных сессий их которых 17 сессий используется для клиентов и 1 для репликации.

Общего места на дисковой подсистеме требуется в 1,5 раза больше, чем доступно для хранения дедуплицированных данных резервного копирования. Это связано с проверкой данных в фоновом режиме и хранении двух check point.

Данные Avamar хранятся в специализированной базе данных GSAN. Ее элементы называются stipe, их максимальный размер - 360 МБ. После прохождения процесса Garbage Collection ненужные блоки помечаются, но не удаляются. Для высвобождения места должен пройти процесс crunch - формирования новых страйпов или сжатие старого страйпа без копирования.

65 % дискового пространства на сервере Avamar отводятся для хранения данных, выше этого объема система переходит в режим read-only. (например, при лицензировании на 1 ТБ, 1 ТБ -
Это 65 % от общей емкости дисковой подсистемы).

Рекомендуется применять Avamar при активности изменения файлов не более 5% за день. Avamar неоптимально работает с аудио, видео, архивами, мультиплексированными данными.

Рекомендуют подвергать резервному копированию не более 2 ТБ на одном клиенте. Максимальный объем дедуплицированных данных, хранимых в RAIN Avamar - 32 ТБ.

Конкурент Avamar - Pure Disk. У него лицензии дешевле, но взимаются за объем до дедупликации. У Avamar лицензии считаются после дедупликации.

Symmetrix V-Max - новое поколение Hi-End массивов от компании EMC

14 апреля 2009 г. корпорация EMC анонсировала новое поколение систем храненияданных высшего класса Symmetrix V-Max.

Система позиционируется как инфраструктурная основа виртуальных центров обработки данных.

Основная новинка - Virtual Matrix Architecture. Новая архитектура позволяет масштабировать систему значительно больше, чем предыдущая архитектура Direct Matrix.

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

СХД поддерживает набор дисков - Flash (диски второго поколения по 200 и 400 ГБ), Fibre Channel, and SATA. Позволяет более удобно организовать уровневую группировку данных на дисковых подсистемах разной производительности и стоимости. Количество дисков, размещаемое в системе - от 96 до 2400. Полезный объем дисковой подсистемы - до 2 ПБ. В системе может быть размещено до 944 ГБ зеркалированной памяти, до 128 портов Fibre Channel, 64 портов FICON, 64 портов Gigabit Ethernet или iSCSI.

Разработана новая версия операционной среды Enginuity - 5874.

Более подробно тут и тут.

Запрос пароля при удалении Symantec Antivirus

Памятка для преодоления запроса пароля при удалении антивируса Symantec.

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

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\LANDesk\VirusProtect6\CurrentVersion\AdministratorOnly\Security параметр UseVPUninstallPassword=1

"1" надо заменить на "0" и перезагрузиться. После этого пароль при удалении ПО запрашиваться не будет.