четверг, 29 октября 2009 г.
понедельник, 26 октября 2009 г.
понедельник, 21 сентября 2009 г.
Смысл и предназначение Microsoft Office SharePoint Server
О Microsoft Office SharePoint Server, внедренном на предприятии (часто внедренном стихийно), довольно часто можно услышать смешанные отзывы – часто говорят, что система непонятно для чего предназначенная, трудноадминистрируемая и прочее.
Часто приводят в пример свободное ПО, предназначенное для узких целей – к примеру, средства для организации Интернет-форумов – и говорят о них как о замене SharePoint. Мол, «для коллективных обсуждений удобнее пользоваться таким-то таким-то форумом, и просто и быстро и и администрировать проще».
В общем, отзывов очень много и все разные. Хотелось бы резюмировать несколько аспектов моего видения данного продукта… Дело в том, что компания Microsoft в разработке и позиционировании многих своих продуктах руководствуется принципом платформы, или, если хотите – конструктора. Касается это не только MOSS; яркий пример – продукты System Center, скажем, System Center Operations Manager. Инсталлировав этот продукт «из коробки» - мы мало что получим кроме минимальных данных о доступности базовых сервисов, на которые мы его «натравим». Полезность близка к нулю. А в другой ситуации, когда мы используем проектный подход в пику стихийному использованию, то есть: проводим исследование потребностей и требований, формируем концепцию решения мониторинга и управления ИТ-инфраструктурой, расписываем сценарии инсталляции, администрирования и эксплуатации, сформировав системные требования для данной конкретной ситуации – мы получаем решение, а не инсталляцию продукта. Это решение представляет собой идею, стратегию, воплощенную при помощи какой-то платформы-конструктора. В общем, это почти то же самое, о чем я говорил в предыдущем посте про хорошую AD и плохую AD.
О платформе какого рода следует говорить касательно MOSS? Есть много замечательных картинок, вроде приведенной мной, которая, собственно, все и объясняет:
Итак, SharePoint – это платформа для организации:
1. Совместной работы
2. Корпоративного портала
3. Управления содержимым
4. Управления бизнес-процессами
5. Бизнес-анализа
6. Корпоративного поиска
Итак, стоит пораздумать над тем, что MOSS – это в первую очередь платформа-конструктор для реализации с помощью ее средств самых различных решений по вышеуказанным направлениям. И эту платформу можно оттачивать и настраивать под самые различные нужды, и уже потом – судить о быстродействии, эффективности и простоте использования. И самое главное в самом начале – понять, что же мы хотим получить в итоге, какую систему, для решения каких задач.
А еще MOSS очень интересно рассматривать в качестве платформы интеграции бизнес-приложений! Но это, как писали братья Стругацкие, уже совсем другая история… И совсем другой пост, который, возможно, тут появится в скором времени… Можно делать заявки :)
А что же происходит в не самом лучшем случае? Представьте такую ситуацию – Вы купили партию строй
материалов: цемент, камень, брус, кирпич, арматура, песок, пеноблоки, стекло, доски, шифер… огромную кучу всего подряд. Затем пытаемся использовать эти материалы сразу как есть: шифером пытаемся укрыться от дождя, доски пытаемся сложить вокруг себя так, чтобы не дуло и не морозило, а пеноблоки начинаем класть, не посчитав их количество и не представляя, что хотим из них сложить в итоге. Ну, какие отзывы мы услышим от того, кто всем этим будет заниматься? :)
Ну вот, собственно, такие мысли о предназначении ПО и стройматериалов :) Удачи Вам и бесперебойного функционирования Вашей ИТ-инфраструктуры, а главное – светлой и ясной погоды в личной жизни!
Часто приводят в пример свободное ПО, предназначенное для узких целей – к примеру, средства для организации Интернет-форумов – и говорят о них как о замене SharePoint. Мол, «для коллективных обсуждений удобнее пользоваться таким-то таким-то форумом, и просто и быстро и и администрировать проще».
В общем, отзывов очень много и все разные. Хотелось бы резюмировать несколько аспектов моего видения данного продукта… Дело в том, что компания Microsoft в разработке и позиционировании многих своих продуктах руководствуется принципом платформы, или, если хотите – конструктора. Касается это не только MOSS; яркий пример – продукты System Center, скажем, System Center Operations Manager. Инсталлировав этот продукт «из коробки» - мы мало что получим кроме минимальных данных о доступности базовых сервисов, на которые мы его «натравим». Полезность близка к нулю. А в другой ситуации, когда мы используем проектный подход в пику стихийному использованию, то есть: проводим исследование потребностей и требований, формируем концепцию решения мониторинга и управления ИТ-инфраструктурой, расписываем сценарии инсталляции, администрирования и эксплуатации, сформировав системные требования для данной конкретной ситуации – мы получаем решение, а не инсталляцию продукта. Это решение представляет собой идею, стратегию, воплощенную при помощи какой-то платформы-конструктора. В общем, это почти то же самое, о чем я говорил в предыдущем посте про хорошую AD и плохую AD.
О платформе какого рода следует говорить касательно MOSS? Есть много замечательных картинок, вроде приведенной мной, которая, собственно, все и объясняет:
Итак, SharePoint – это платформа для организации:
1. Совместной работы
2. Корпоративного портала
3. Управления содержимым
4. Управления бизнес-процессами
5. Бизнес-анализа
6. Корпоративного поиска
Итак, стоит пораздумать над тем, что MOSS – это в первую очередь платформа-конструктор для реализации с помощью ее средств самых различных решений по вышеуказанным направлениям. И эту платформу можно оттачивать и настраивать под самые различные нужды, и уже потом – судить о быстродействии, эффективности и простоте использования. И самое главное в самом начале – понять, что же мы хотим получить в итоге, какую систему, для решения каких задач.
А еще MOSS очень интересно рассматривать в качестве платформы интеграции бизнес-приложений! Но это, как писали братья Стругацкие, уже совсем другая история… И совсем другой пост, который, возможно, тут появится в скором времени… Можно делать заявки :)
А что же происходит в не самом лучшем случае? Представьте такую ситуацию – Вы купили партию строй
материалов: цемент, камень, брус, кирпич, арматура, песок, пеноблоки, стекло, доски, шифер… огромную кучу всего подряд. Затем пытаемся использовать эти материалы сразу как есть: шифером пытаемся укрыться от дождя, доски пытаемся сложить вокруг себя так, чтобы не дуло и не морозило, а пеноблоки начинаем класть, не посчитав их количество и не представляя, что хотим из них сложить в итоге. Ну, какие отзывы мы услышим от того, кто всем этим будет заниматься? :)Ну вот, собственно, такие мысли о предназначении ПО и стройматериалов :) Удачи Вам и бесперебойного функционирования Вашей ИТ-инфраструктуры, а главное – светлой и ясной погоды в личной жизни!
понедельник, 14 сентября 2009 г.
Active Directory - что такое хорошо и что такое плохо.
Эникейщик к нам пришел
И сказал нам кроха:
"Active Directory - хорошо,
А развернули плохо."
Мы часто слышим "плохая AD", "грамотная AD", "кривая AD" и много других самых разнообразных эпитетов в адрес того или иного частного случая развертывания данной службы каталогов. Если попытаться спросить, что же означает на деле то или иное определение - то администратор (а зачастую, как бы ни было печально, и инженер) с трудом могут сформулировать, "что такое хорошо и что такое плохо".
Попытаемся прикинуть данные определения хотя бы на верхнем уровне. Итак, что же такое оптимальная структура AD?
Это служба каталогов Microsoft Active Directory, которая:
Спланирована, спроектирована и внедрена согласно проведенным исследованиям сетевой инфраструктуры, системного окружения, аппаратных платформ а также организационно-иерархической структуры организации и принятой в ней политик безопасности а также с учетом рекомендаций производителя и подтвержденных им лучших практик внедрения.
Значит это ровно следующее: спроектирована структура AD, в которой учитывается существующая инфраструктура LAN предприятия, связи всех территориальных подразделений, а также заранее спланированы все изменения, которые в эту инфраструктуру придется внести перед внедрением AD. Как пример - от того, чтобы найти и исключить банальный "перехлест" адресации (если в компании существуют изолированные подсети с одинаковой адресацией - в тех подразделениях, которые планируются к объединению), вплоть до того, чтобы найти какое-нибудь отдаленное подразделение, где IP-адреса хостам выдаются вручную системными администраторами.
На этой стадии - стадии исследований - также необходимо уберечь себя от потенциальной дальнейшей беготни по поставщикам оборудования и ПО; необходимо тщательно продумать и спланировать закупки и спецификации аппаратного и программного обеспечения с учетом роста инфраструктуры и обеспечения ее отказоустойчивости.
Отдельной строкой необходимо подойти к исследованию организационной структуры предприятия, иерархии отделов, структуры подчинения, размещению ИТ-отделов и специалистов в филиалах и так далее - исходя из этого мы будем планировать количество лесов, доменов, а также количество и структуру Organizational Units.
И вот у нас появляются результаты предпроектных исследований, оформленные в красивый отчет. Но этого мало для начала внедрения. Нам необходимо, чтобы проектируемая структура AD соответствовала не только требованиям организации, но и рекомендациям и лучшим практикам от производителя - Microsoft, так как нам необходимо обеспечить еще и отказоустойчивость, масштабируемость и надежность внедренной Системы. Best practicies переписывать особой нужды не вижу - все они доступны в открытых источниках. Пользуясь случаем, хочу еще раз настоятельно порекомендовать к прохождению курсы от Microsoft по планированию, дизайну и проектированию архитектуры Active Directory. Собственно, разобравшись в ней, вы поймете, что все описанное в данном посте - лишь краткие заметки о замечательной, красивой и интересной работе - организации единой службы каталогов предприятия.
На все сказанное можно резонно возразить: "У нас AD развернута стихийно, на коленке - и все работает, все десять филиалов получают доступ к файловым серверам, принтерам, к корпоративному порталу и почте - и у нас все окей, ничего не отказывает, ничего не надо реконфигурировать и изменять, все крутится на одном контроллере домена и ничего не падает".
На это возражение я могу привести ряд ситуаций, над которыми прошу вас подумать:
Хорошей погоды всем!
И сказал нам кроха:
"Active Directory - хорошо,
А развернули плохо."
Мы часто слышим "плохая AD", "грамотная AD", "кривая AD" и много других самых разнообразных эпитетов в адрес того или иного частного случая развертывания данной службы каталогов. Если попытаться спросить, что же означает на деле то или иное определение - то администратор (а зачастую, как бы ни было печально, и инженер) с трудом могут сформулировать, "что такое хорошо и что такое плохо".
Попытаемся прикинуть данные определения хотя бы на верхнем уровне. Итак, что же такое оптимальная структура AD?
Это служба каталогов Microsoft Active Directory, которая:
Спланирована, спроектирована и внедрена согласно проведенным исследованиям сетевой инфраструктуры, системного окружения, аппаратных платформ а также организационно-иерархической структуры организации и принятой в ней политик безопасности а также с учетом рекомендаций производителя и подтвержденных им лучших практик внедрения.
Значит это ровно следующее: спроектирована структура AD, в которой учитывается существующая инфраструктура LAN предприятия, связи всех территориальных подразделений, а также заранее спланированы все изменения, которые в эту инфраструктуру придется внести перед внедрением AD. Как пример - от того, чтобы найти и исключить банальный "перехлест" адресации (если в компании существуют изолированные подсети с одинаковой адресацией - в тех подразделениях, которые планируются к объединению), вплоть до того, чтобы найти какое-нибудь отдаленное подразделение, где IP-адреса хостам выдаются вручную системными администраторами.
На этой стадии - стадии исследований - также необходимо уберечь себя от потенциальной дальнейшей беготни по поставщикам оборудования и ПО; необходимо тщательно продумать и спланировать закупки и спецификации аппаратного и программного обеспечения с учетом роста инфраструктуры и обеспечения ее отказоустойчивости.
Отдельной строкой необходимо подойти к исследованию организационной структуры предприятия, иерархии отделов, структуры подчинения, размещению ИТ-отделов и специалистов в филиалах и так далее - исходя из этого мы будем планировать количество лесов, доменов, а также количество и структуру Organizational Units.
И вот у нас появляются результаты предпроектных исследований, оформленные в красивый отчет. Но этого мало для начала внедрения. Нам необходимо, чтобы проектируемая структура AD соответствовала не только требованиям организации, но и рекомендациям и лучшим практикам от производителя - Microsoft, так как нам необходимо обеспечить еще и отказоустойчивость, масштабируемость и надежность внедренной Системы. Best practicies переписывать особой нужды не вижу - все они доступны в открытых источниках. Пользуясь случаем, хочу еще раз настоятельно порекомендовать к прохождению курсы от Microsoft по планированию, дизайну и проектированию архитектуры Active Directory. Собственно, разобравшись в ней, вы поймете, что все описанное в данном посте - лишь краткие заметки о замечательной, красивой и интересной работе - организации единой службы каталогов предприятия.
На все сказанное можно резонно возразить: "У нас AD развернута стихийно, на коленке - и все работает, все десять филиалов получают доступ к файловым серверам, принтерам, к корпоративному порталу и почте - и у нас все окей, ничего не отказывает, ничего не надо реконфигурировать и изменять, все крутится на одном контроллере домена и ничего не падает".
На это возражение я могу привести ряд ситуаций, над которыми прошу вас подумать:
- Что вы будете делать, если не дай Бог (тот, в которого Вы верите) - полыхнет контроллер домена? Железо не вечно, а данные каталога имеют намного ценность намного более высокую, чем это железо. Как вы производите резервное копирование AD? Сколько раз и в скольких различных ситуациях вы тестировали аварийное восстановление служб каталогов? На сколько тысяч рублей будет урезана Ваша зарплата, если сотрудники предприятия на один день останутся без доступа к корпоративным ресурсам?
- Какие Вы предпримете действия, если ваша компания будет приобретена другой компанией, или, дай вам Бог (тот, в которого Вы верите) - ваша компания приобретет пару-тройку предприятий? Выдержит ли ваша структура AD расширение и объединение с другими предприятиями-модулями? Сколько ночей Вам придется провести на работе, "руками" перенося данные о пользователях из другого домена?
- Разрешения на ресурсы выдаются отдельным пользователям или группам пользователей? Если отдельным пользователям - представьте, сколько времени Вы убьете на выдачу разрешений на какой-нибудь узел корпоративного портала, когда ваша компания вырастет раза хотя бы в два.
- И многое, многое, многое другое. Надеюсь, что у меня получилось разбудить Вашу фантазию! Проблемы с вводом новых сервисов, трудноотлавливаемые проблемы в работе бизнес-приложений, неработающие схемы аутентификации (привет, Kerberos!), головная боль с паролями пользователей и назначением им прав, разруливание ситуаций со сложным трастами между десятками доменов и вообще проблемы со ВСЕЙ ИТ-инфраструктурой... В общем, мрак и ужас.
Хорошей погоды всем!
среда, 9 сентября 2009 г.
AIIM ECM Practitioner, MCTS и прочее интересное.
Здравствуйте.
17го сентября сего года отправляюсь в Москву с целью прохождения курса AIIM ECM Practitioner. С нетерпением жду сего события, программа обучения обещает быть весьма интересной. Рекомендую к ознакомлению:
http://www.docflow.ru/ecm_practitioner/
Также хотелось бы подчеркнуть, что данный именитый курс впервые читается в России. Более подробно с данным видом обучения можно ознакомиться у авторов:
http://www.aiim.org/Education/ECM-Enterprise-Content-Management-Training-Courses.aspx
На данный момент регистрация закончена, но если вдруг Вам очень хочется туда попасть - ко мне можно обратиться в комментариях, могу помочь с продлением регистрации.
В дальнейшем в блоге будет размещен отчет о курсе - краткое ревью, а также описание моего дальнейшего пути в части получения сертификата ECM Practitioner - по окончанию курса дается три попытки сдать экзамен в течение трех месяцев.
Надеюсь в ближайшем будущем присовокупить данные компетенции к своим MCTS и MCBMSS -) Пожелайте удачи)
17го сентября сего года отправляюсь в Москву с целью прохождения курса AIIM ECM Practitioner. С нетерпением жду сего события, программа обучения обещает быть весьма интересной. Рекомендую к ознакомлению:
http://www.docflow.ru/ecm_practitioner/
Также хотелось бы подчеркнуть, что данный именитый курс впервые читается в России. Более подробно с данным видом обучения можно ознакомиться у авторов:
http://www.aiim.org/Education/ECM-Enterprise-Content-Management-Training-Courses.aspx
На данный момент регистрация закончена, но если вдруг Вам очень хочется туда попасть - ко мне можно обратиться в комментариях, могу помочь с продлением регистрации.
В дальнейшем в блоге будет размещен отчет о курсе - краткое ревью, а также описание моего дальнейшего пути в части получения сертификата ECM Practitioner - по окончанию курса дается три попытки сдать экзамен в течение трех месяцев.
Надеюсь в ближайшем будущем присовокупить данные компетенции к своим MCTS и MCBMSS -) Пожелайте удачи)
понедельник, 2 февраля 2009 г.
Механизмы резервного копирования и восстановления службы каталогов Microsoft Active Directory
Для обеспечения резервного копирования и восстановления Active Directory служит ряд стандартных технологий, методов и инструментов.
Одним из основных гарантов работоспособности любой информационной системы (в разрезе целостности и сохранности данных) является тщательно и разумно разработанный механизм резервного копирования данных и план по их восстановлению в различных ситуациях.
Рекомендуемый инструмент резервного копирования и восстановления AD – стандартный инструмент в поставке Windows 2003 – ntbackup. Для того, что сохранить текущее состояние контроллера домена, достаточно выполнять регулярную архивацию System State (состояние системы), которое включает в себя такие компоненты:
1. Файл ntds.dit – база данных AD
2. Реестр контроллера домена
3. База данных Certification Authority (служб сертификации)
4. Папка SYSVOL, хранящая сценарии входа в систему и шаблоны групповых политик домена
5. Системные файлы, необходимые для загрузки операционной системы
6. База данных регистрации классов COM+, которая содержит информацию о приложениях COM+
7. Сведения Cluster Services (служб кластеров), в том случае, если данный сервер является компонентом кластера.
Восстановление состоянии домена контроллера из архива проводится при помощи все той же утилиты ntbackup. В зависимости от того, какую цель мы ставим перед этой операцией, можно провести восстановление различного характер – Primary и Normal; соответственно основное и обычное. Обычно также именуется непринудительным.
Primary, основное – используется в том случае, когда мы преследуем цель восстановить информацию AD в рамках всего домена. Может применяться в ситуации, когда один или несколько контроллеров домена выходят из строя.
Выполняется это восстановление при помощи утилиты ntbackup, в расширенных свойствах восстановления необходимо установить атрибут пометки восстанавливаемых данных как основных для всех реплик.
Normal, обычное (непринудительное) - этот тип восстановления используется тогда, когда необходимо восстановить состояние одного контроллера-домена к предыдущему (то есть к состоянию на момент последней архивации, которая производилась во время штатной, корректной его работы). Данные на восстановленном домене будут актуализированы после первого же сеанса репликации (если, само собой, в домене наличествуют другие контроллеры домена и корректно настроена репликация). У объектов AD существует свойство USN – Update Sequence Numbers, номер последовательного восстановления. Он определяет «свежесть» информации об объекте. При репликации объект с более низким USN будет перезаписан объектом с более высоким USN (по абсолютному значению).
Кроме уже описанных видов восстановления, применимых касательно утилиты ntbackup, существует также еще один тип восстановления – принудительное (authoritative). Данную функциональность обеспечивает утилита командной строки ntdsutil. Это восстановление используется в сочетании с вышеописанными методами, когда имели место, к примеру, ошибки в администрировании AD, повлекшие за собой потерю важных данных. Скажем, был ошибочно удален объект или группа объектов на одном из контроллеров домена. Затем это изменение было среплицировано на все остальные контроллеры домена, в итоге чего организация теряет сведения, удаление которых не было легальным образом предусмотрено. Выходом может стать принудительное восстановление, которое помечает восстановленные из архива объекты как достоверные – и в дальнейшем эти объекты и их свойства реплицируются на все остальные контроллеры домена, в результате чего мы восстанавливаем удаленное доселе подразделение, объект. (Стоит помнить, что AD отслеживает удаленные объекты только в течение времени жизни их захоронения. По истечении этого срока объекты не могут быть восстановлены.)
Принудительное восстановление производится при помощи утилиты командной строки ntdsutil, причем проводится это в DSRM (Directory Services Restore Mode, режим восстановления службы каталогов). Восстановить можно как всю базу данных (команда restore database утилиты ntbackup), так и ее часть, поддерево (restore subtree). Отмеченные объекты восстановления претерпевают изменение USN – авторитативное восстановление увеличивает этот параметр. После выполнения необходимых операций по принудительному восстановлению и перезапуска контроллера домена принудительно восстановленные объекты реплицируются на остальные контроллеры домена. В остальном репликация протекает по обычному сценарию.
Одним из основных гарантов работоспособности любой информационной системы (в разрезе целостности и сохранности данных) является тщательно и разумно разработанный механизм резервного копирования данных и план по их восстановлению в различных ситуациях.
Рекомендуемый инструмент резервного копирования и восстановления AD – стандартный инструмент в поставке Windows 2003 – ntbackup. Для того, что сохранить текущее состояние контроллера домена, достаточно выполнять регулярную архивацию System State (состояние системы), которое включает в себя такие компоненты:
1. Файл ntds.dit – база данных AD
2. Реестр контроллера домена
3. База данных Certification Authority (служб сертификации)
4. Папка SYSVOL, хранящая сценарии входа в систему и шаблоны групповых политик домена
5. Системные файлы, необходимые для загрузки операционной системы
6. База данных регистрации классов COM+, которая содержит информацию о приложениях COM+
7. Сведения Cluster Services (служб кластеров), в том случае, если данный сервер является компонентом кластера.
Восстановление состоянии домена контроллера из архива проводится при помощи все той же утилиты ntbackup. В зависимости от того, какую цель мы ставим перед этой операцией, можно провести восстановление различного характер – Primary и Normal; соответственно основное и обычное. Обычно также именуется непринудительным.
Primary, основное – используется в том случае, когда мы преследуем цель восстановить информацию AD в рамках всего домена. Может применяться в ситуации, когда один или несколько контроллеров домена выходят из строя.
Выполняется это восстановление при помощи утилиты ntbackup, в расширенных свойствах восстановления необходимо установить атрибут пометки восстанавливаемых данных как основных для всех реплик.
Normal, обычное (непринудительное) - этот тип восстановления используется тогда, когда необходимо восстановить состояние одного контроллера-домена к предыдущему (то есть к состоянию на момент последней архивации, которая производилась во время штатной, корректной его работы). Данные на восстановленном домене будут актуализированы после первого же сеанса репликации (если, само собой, в домене наличествуют другие контроллеры домена и корректно настроена репликация). У объектов AD существует свойство USN – Update Sequence Numbers, номер последовательного восстановления. Он определяет «свежесть» информации об объекте. При репликации объект с более низким USN будет перезаписан объектом с более высоким USN (по абсолютному значению).
Кроме уже описанных видов восстановления, применимых касательно утилиты ntbackup, существует также еще один тип восстановления – принудительное (authoritative). Данную функциональность обеспечивает утилита командной строки ntdsutil. Это восстановление используется в сочетании с вышеописанными методами, когда имели место, к примеру, ошибки в администрировании AD, повлекшие за собой потерю важных данных. Скажем, был ошибочно удален объект или группа объектов на одном из контроллеров домена. Затем это изменение было среплицировано на все остальные контроллеры домена, в итоге чего организация теряет сведения, удаление которых не было легальным образом предусмотрено. Выходом может стать принудительное восстановление, которое помечает восстановленные из архива объекты как достоверные – и в дальнейшем эти объекты и их свойства реплицируются на все остальные контроллеры домена, в результате чего мы восстанавливаем удаленное доселе подразделение, объект. (Стоит помнить, что AD отслеживает удаленные объекты только в течение времени жизни их захоронения. По истечении этого срока объекты не могут быть восстановлены.)
Принудительное восстановление производится при помощи утилиты командной строки ntdsutil, причем проводится это в DSRM (Directory Services Restore Mode, режим восстановления службы каталогов). Восстановить можно как всю базу данных (команда restore database утилиты ntbackup), так и ее часть, поддерево (restore subtree). Отмеченные объекты восстановления претерпевают изменение USN – авторитативное восстановление увеличивает этот параметр. После выполнения необходимых операций по принудительному восстановлению и перезапуска контроллера домена принудительно восстановленные объекты реплицируются на остальные контроллеры домена. В остальном репликация протекает по обычному сценарию.
Подписаться на:
Сообщения (Atom)