Міграція базової інфраструктури Microsoft частина 1, Інтеграція додатків і даних, Бази даних, статті

Введення.


Тема міграції базової інфраструктури Microsoft не нова. Але повної і самодостатньою інформації про проведення цього процесу дуже мало, якщо не сказати, що такої інформації взагалі немає. На просторах мережі Інтернет можна знайти дуже багато статей, що описують процес міграції, але всі ці статті є якимись “недогризками” та повної картини не розкривають. Якщо говорити про міграцію на нові платформи, то тут інформації ще менше.


Мені хотілося б розкрити цю тему в більшому обсязі, розповісти про особливості міграції в реальних інфраструктурах. Буде враховуватися специфіка роботи різних інформаційних систем, як такі системи необхідно мігрувати, в якій послідовності.


Однією статті для розгляду матеріалу не вистачить (або це буде дуже велика стаття), тому буде кілька статей. Кінцевий обсяг матеріалу поки не відомий. Писати буду по мірі можливостей, постараюся не затягувати з цим процесом.


Що будемо вважати базовою інфраструктурою, і що в неї буде входити?



Зараз все більше і більше організацій використовують Exchange-сервер в якості засобу об’єднаних комунікацій. Exchange безпосередньо залежить від Active Directory, і міграція служби каталогів безумовно вплине на роботу Exchange-користувачів. Документація з міграції Active Directory є, але в цій документації не описується процес міграції AD спільно з Exchange. У свою чергу, в інших документах описується міграція Exchange, але вона не розглядається спільно з міграцією Active Directory. Приблизно ту ж саму картину я спостерігав на проектах, в яких брало участь кілька архітекторів – один з AD, другий по Exchange. Найчастіше їхні дії не були узгоджені – міграція двох систем проходила кілька ізольовано, особливості спільної міграції не враховувалися. Виходило, що одна система (архітектор) заважала другий (іншому).


Є певні особливості міграції серверів Microsoft SQL Server. Включимо в міграцію і їх.


Що будемо вважати міграцією? Міграцією будемо вважати перенесення ресурсів з одного або декількох лісів в цільової ліс. Така модель найчастіше зустрічається на практиці.


Сам процес міграції це тільки півсправи (швидше за все навіть менше). Міграція процес складний, довгий, включає в себе безліч завдань, розподілених у часі, виконання яких дозволить домогтися якогось результату, досягти поставлених цілей. Я фактично назвав визначення поняття проект. Для виконання проекту потрібен певний підхід. Методологій з управління проектами багато, тема велика, в цій статті розглядатися не буде. Хороші рекомендації з управління проектами дані в методології MSF (Microsoft Solution Framework). Деякі вважають, що ця модель підходить тільки для розробників і до інфраструктурних проектів не належить. Насправді це не так. Матеріал методології добре підходить і до інфраструктурних проектів, необхідно тільки трохи поабстрагіровать. У цій методології не буде описано “як і що робити”, в ній не буде жорстких правил ведення проектів, але в ній даються цінні поради, які вам допоможуть виконати будь-який проект, не тільки ITшний.


Також в проектуванні допоможуть стандарти, наприклад, ГОСТи.
З них вам також необхідно вибрати певні рекомендації, які вам допоможуть виконати проект успішно. Знайти ГОСТи для автоматизованих систем можна тут – http://www.rugost.com/index.php?option=com_content&task=category&sectionid=6&id=22&Itemid=53


Наприклад, я для себе виробив якусь методику, яка є гібридом ГОСТів та методології MSF. Застосовую її на практиці.


Деякі рекомендації з ведення проектів, а точніше з управління проектною групою, можна отримати з книги Страуструпа “Мова програмування С + +”, друге і третє видання. У цій книзі є окрема глава, присвячена проектуванню.


Контролювати хід проекту вам допоможе Microsoft Project. Є гарна книга Гультяева А.К. з управління проектами в Microsoft Project. Раджу прочитати.


Вихідні дані.


Які у нас є вихідні дані?


У нас є вихідна інфраструктура, що складається з одного лісу та кількох доменів.


Ім’я кореневого домена – source.com / SOURCE. Дочірній домен – child1.source.com/CHILD1. Версії контролерів доменів в source.com – Windows Server 2003 з SP2, в child1 – Windows 2000 Server з SP4. В доменах працюють декілька користувачів. Робочі станції – 2000, XP, Vista, Windows 7. Є сервери Windows 2000 Server, Windows Server 2003/2008R1/2008R2.


У кожному домені встановлений Exchange-сервер версії 2003 з SP2. Якщо на Exchange-сервер не встановлений SP2, то необхідно це зробити до міграції поштових скриньок користувачів. Exchange 2010 підтримує міграцію поштових скриньок тільки з версій Exchange Server 2003 SP2 і Exchange Server 2007 SP2.


Є певні вимоги до версій контролерів доменів при міграції пошти на Exchange Server 2010 (або на Exchange 2007). Про ці особливості трохи пізніше.


Ми вже спроектували цільову інфраструктуру і навіть її впровадили. В якості цільової інфраструктури буде виступати домен target.com / TARGET. Версія контролерів доменів Windows Server 2008 R2.


На окремому сервері встановлено Exchange Server 2010. На цьому сервері встановлені всі ролі, а точніше ролі Hub, CAS і Mailbox. За обробку зовнішньої пошти зараз відповідає один із серверів у вихідному домені. Після міграції цю роль на себе візьме ще один сервер у новій інфраструктурі – Exchange Server 2010 з роллю Edge Transport.


У нас також будуть різні типи серверів у вихідному домені. Нам їх теж доведеться мігрувати в нову інфраструктуру. Про міграції серверів трохи пізніше.


Інтеграція.


Міграція є процесом досить довгим і сам процес передбачає довгострокове співіснування двох систем – старої і нової.


Тому нам необхідно інтегрувати нашу поточну інфраструктуру з цільовою.


Дозвіл імен.


З чого почати інтеграцію? Найкраще з настройки розпізнавання імен між інфраструктурами. Нам необхідно, щоб смігрірованние ресурси могли дозволяти імена несмігрірованних ресурсів, і навпаки. Найбільш популярні механізми вирішення імен в Windows-мережах – це DNS і NETBIOS.


Будемо вважати, що DNS-сервери розгорнуті на контроллерах доменів. Обслуговують ці DNS-сервери зони для свого розділу і зону _msdcs.корневой_домен_леса. Зони інтегровані в Active Directory.


Як правило, вистачає налаштування дозволу тільки DNS-імен між інфраструктурами.


Існує кілька способів настроювання такої взаємодії: пересилання, вторинні зони, зони-заглушки.


Розглянемо перший спосіб – пересилання:



Загалом-то, ніщо нам не заважає використовувати цей механізм. Спочатку ми налаштовуємо у вихідному домені пересилання для цільового домену. Для пересилання ми вказуємо найближчі DNS-сервери цільового домену. Що означає найближчі? Як правило, в багато середовищі, для регіональної площадки виділяється окремий домен (в нашому випадку це child1.source.com). Зараз звичайно від такої моделі намагаються відходити і переходити до однодоменних моделі. Але не вважайте однодоменних модель небудь правилом. Іноді вона може вам не підійти. Все залежить від вимог. При міграції в новий домен, комп’ютери будуть реєструвати A-записи на локальних контроллерах домена, тобто на контролерах домену тієї ж фізичної майданчика, що і у вихідному лісі (за умови, що ми правильно налаштували конфігурацію мережевої карти клієнтів DNS; про це трохи пізніше). Тому було б правильним налаштувати пересилку саме на ці локальні контролери доменів.


У цільовому домені ми проробляємо теж саме – налаштовуємо пересилання для вихідного домену між найближчими DNS-серверами.


Якщо вихідні DNS-сервери – Windows 2000, необхідно використовувати вторинні зони або продумати спосіб дозволу імен спільно з глобальними пересилками на DNS-сервери цільового домену.


Починаючи з Windows Server 2008, з’явилася можливість реплицировать записи пересилань між DNS-серверами. Можна скористатися цим механізмом, щоб не робити одну й ту ж саму роботу кілька разів.


Другий механізм – використання вторинних зон:



Тут ми дозволяємо пересилання зони між серверами початкового і цільового доменів. Створюємо вторинні зони: на вихідних DNS-серверах вторинні зони для цільового домену, на цільових для вихідного домену. В якості master-сервера використовуємо найближчий DNS-сервер. Налаштовуємо оповіщення при змінах. Число змін до оповіщення – 1.


Третій спосіб – використання зон-заглушок:



Цей функціонал з’явився в Windows Server 2003. За допомогою зон-заглушок ми можемо отримувати інформацію про авторитетних DNS-серверах – NS-і A-записи серверів, обслуговуючих зазначену зону. Причому, ця інформація буде ще й динамічно оновлюватися.


Загалом-то, спосіб відмінний, але для нашого прикладу підходить лише частково. DNS-сервери з домена child1 отримають NS / A-записи для всіх DNS-серверів домену target.com (випадки з DisallowNSAutoCreation не будемо розглядати). Для розпізнавання імен, вони також будуть звертатися до одного з цих NS-серверів. Коли ми смігріруем комп’ютер в новий домен, він зареєструється на “новому”, найближчому DNS-сервер. Ще несмігрірованние комп’ютери будуть звертатися до старих DNS-серверів, а ті в свою чергу на якийсь DNS-сервер з нового домену. На який? Чи встигне нова A-запис для смігрірованного комп’ютера реплицироваться на цей якийсь DNS-сервер? Відповісти на це питання важко. Тому зони-заглушки зі старого домену в новий, для нашої конфігурації, не підійдуть. А ось в протилежну сторону ми їх можемо використовувати.


Починаючи з Windows Server 2008 R1, у нас є можливість реплицировать зони цього типу між DNS-серверами. Варто скористатися цією можливість, тим більше цільової ліс у нас Windows Server 2008 R2.


Хотілося б відзначити декілька плюсів і мінусів цих трьох способів.


Спосіб з пересилками досить простий в конфігурації, при цьому трафік передачі зони дорівнює нулю. Але трафік запитів більше, ніж у вторинних зон. Є деякі обмеження при міграції з Windows Server 2000: немає підтримки умовних пересилань. Також є проблеми з актуальністю даних. Наприклад, якщо якась запис зміниться, скажімо, помінявся IP-адреса комп’ютера, то зміни будуть відображені на пересилає стороні тільки після закінчення терміну кешування запису і при повторному запиті. Це стосується і способу з зонами-заглушками. Що не скажеш про вторинні зонах, де інформація більш актуальна (за умови налаштування сповіщень при зміні).


При використанні вторинної зони трафік передачі зони буде більше ніж у першого і третього способу, але трафік запитів буде дорівнює нулю. Великим мінусом є необхідність у спостереженні за успішністю передачі зони.


Варіант з зонами-заглушками має практично ті ж плюси і мінуси, що і спосіб з пересилками.


Три способи. Який краще? Спосіб з пересилками є найбільш простим. Зони-заглушки можна використовуватися лише частково. Другий спосіб є більш складним, а значить, збільшується вірогідність відмови. На питання я так і не відповів. Вирішуйте самі.


Якщо між взаємодіючими системами (клієнтами, DNS-серверами), є брандмауери, нам необхідно вирішити трафік DNS – 53 TCP / UDP.


Детальніше про управління серверів DNS – http://technet.microsoft.com/en-us/library/cc794771% 28WS.10% 29.aspx


Тепер трохи про дозвіл NETBIOS-імен. Основним способом вирішення імен в системах Windows 2000 і вище є DNS, але є додатки, які до цих пір використовують NETBIOS-функції і короткі імена. Microsoft зробила певний крок, щоб позбутися від цього. Тепер, починаючи з Vista/Win2008, NETBIOS-функції не підтримуються. Сподіваюся, що незабаром ми позбудемося NETBIOS-імен назавжди. Але відсутність підтримки зовсім не означає, що такі програми не будуть працювати в лісах Windows 2008 R2. Використання NETBIOS-імен також триває.


Є три способи дозволу NETBIOS-імен: файли LMHOSTS, широкомовні розсилання і WINS-сервери.


Для LMHOSTS нічого переносити не потрібно, такі файли мігрують разом з комп’ютерами. Інша справа, якщо ви будете в процесі міграції перейменовувати системи. В цьому випадку вам необхідно вручну підправити ці файли. На широкомовлення ми не зможемо вплинути, тому тут нічого зробити не можна. Для міграції WINS-інфраструктури ми можемо скористатися одним з таких способів:


1) Перенести інфраструктуру WINS після міграції ресурсів Active Directory:



2) Налаштувати реплікацію між новими і старими WINS-серверами, переключити комп’ютери на нову інфраструктуру до міграції ресурсів AD:



3) Як і другий спосіб, але комп’ютери перемикаємо після міграції в новий ліс:



Перший і третій спосіб хороший тим, що ми не стикаємося з проблемами актуальності і збіжності даних. Всі комп’ютери спрямовані на одні й ті ж WINS-сервери (смігрірованние і несмігрірованние комп’ютери), а значить, є єдина точка, як поновлення ресурсів, так і їх дозволу. Потім нам доведеться налаштовувати реплікацію між інфраструктурами (або для третього способи ми вже це зробили) і, коли все ресурси перенесені, необхідно перемкнути комп’ютери на нові сервери. Якщо перемкнути всі комп’ютери за один раз, то напевно зіткнемося з деякими проблемами при вирішенні імен. Гарантувати перемикання всіх комп’ютерів навряд чи можна у великій інфраструктурі. А якщо перемикати порціями, то збільшиться час міграції.


Краще мати справу з проблемами в менших масштабах і вирішувати їх (запобігати) у міру надходження. Як раз це другий спосіб. Ми спочатку налаштовуємо реплікацію між старим і новим лісом, а потім, перед міграцією, порціями (слотами), перемикаємо комп’ютери на нові WINS-сервери. У цій конфігурації несмігрірованние ресурси дивляться на одні сервери, смігрірованние на інші. Виникає проблема з латентністю реплікації даних між цими системами. Але, як я говорив, нові системи воліють DNS, тому ми навряд чи зіткнемося з проблемами. А якщо і зіткнемося, то, швидше за все, на невеликій частині комп’ютерів.


У нас є можливість інтегрувати DNS з WINS “ом – зробити для DNS-зони WINS-перегляд. Чи потрібно це робити для міграції? Краще не варто. Це зайве ускладнення, яке значною кількістю помилок і вірогідність відмови складних систем все ж таки більше, ніж у простих. Якщо говорити про реальні проблеми, то можуть виникнути помилки при аутентифікації по протоколу Kerberos. І ось чому. Наприклад, користувач запитує деяку службу за коротким імені – SERVICE01. Підставляється якийсь суфікс та ім’я виходить довге – SERVICE01.target.com. Далі запит відправляється на DNS-сервер, в якому для зони target.com налаштований огляд в WINS. Якщо DNS не знаходить в зоні target.com зазначеної записи, він відкине доменні мітки і запросить у WINS “а запис SERVICE01. WINS відповість IP-адресою. Але з якого домену цей запис? WINS – система плоских імен, тому невідомо. DNS-сервер поверне користувачеві відповідь: SERVICE01.target.com = IP-адресу. IP-адреса буде, швидше за все, правильним – пінги пустити можна. Але ось що, якщо користувач хотів звернутися до служби зі старого лісу – service01.source.com. Тут якраз і можуть виникнути проблеми при пошуку служби по ServicePrincipalName. В результаті можуть виникнути проблеми з аутентифікацією по протоколу Kerberos.


Звичайно, ця проблема може і не з’явитися. Все залежить від реалізації програм та операційної системи. Але краще запобігти появі таких помилок заздалегідь, тим більше категорія таких помилок є важко локалізуемой.


Як вчинити, якщо ми вирішили налаштовувати реплікацію бази WINS між інфраструктурами? Реплікувати чи базу тільки між найближчими WINS-серверами або це буде змішана реплікація?


Подивіться на вашу поточну модель реплікації і зробіть за аналогією. Якщо у вас багатодоменному середу і налаштована реплікація між серверами з різних доменів, значить, у вас немає проблем з дублюванням NETBIOS-імен. Якщо є, то варто подумати про те, чи не виникнуть проблеми при міграції в однодоменних структуру. У такій конфігурації можна використовувати реплікацію через магістраль.



Якщо реплікація використовується тільки всередині домену, то настройте реплікацію в межах фізичної майданчика – між серверами з старого домену і серверами тій же майданчика нового домену.



Вимоги до відкриття портів TCP / IP, використовуваних WINS-серверами – http://technet.microsoft.com/ru-ru/library/cc784026% 28WS.10% 29.aspx.


Детальніше про управління сервером WINS – http://technet.microsoft.com/en-us/library/cc739183% 28WS.10% 29.aspx.


Дозволу імен варто приділити особливу увагу. Причому, не тільки при міграції. Помилки, пов’язані з роздільною здатністю імен, складають 80-90% від загальної кількості (якщо не брати до уваги помилки ІТ-фахівців).


На цьому налаштування дозволу імен не закінчується. Ми будемо і далі обговорювати цю тему.


У наступній статті ми продовжимо інтеграцію наших інфраструктур.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*