Переміщення серверів у межах однієї будівлі

Ось мій сценарій: я розробник, який успадкував (невідомі мені) три сервери, розташовані в моєму офісі. Я також успадкував завдання бути адміністратором серверів з явною відсутністю знань про адміністрування сервера та google / ServerFault як орієнтир. На щастя, мені ніколи насправді не довелося фізично контактувати з машинами або вирішувати будь-які проблеми, оскільки вони завжди «просто працювали».

Усі три машини розташовані в одній кімнаті даних і служать наступному призначенню:

Machine1- IIS 8.0, що розміщує ряд внутрішніх додатків
Machine2- сховище даних SQL Server 2008 R2 для внутрішніх додатків
Machine3- дзеркальний сховище SQL Server 2008 R2Machine2

Всі три мають підключені зовнішні жорсткі диски, які часто завершують резервні копії.

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

Крім того, щоб виконати повне резервне копіювання кожного, які міркування мені потрібно зробити, перш ніж гіпотетично натиснути на вимикач живлення та спостерігати за тим, як мій світ рухається?

^{Я усвідомлюю, що далеко не ідеально, щоб усі троє знаходилися в одній кімнаті / приміщенні, але це вже минуло рамки цього питання.}

По-справжньому цікаве запитання, добре поставлений :)

Перед цим кроком потрібно перевірити кілька речей, деякі легкі, а деякі важкі.

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

Охолодження - потрібно перевірити, чи не відбудеться негайне або поступове накопичення тепла, що призведе до перегріву та потенційного відключення сервера. Зазвичай ви можете шукати максимальну потужність (у ватах) або тепло (у BTU), яку кожен сервер може отримати із веб-сайту виробників - повідомте про це керівнику будівлі та отримайте від них письмове підтвердження про те, що охолодження в цьому місці буде справлятися .

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

"Інші з'єднання" - чи знаєте ви, чи є у ваших серверів будь-яке інше з'єднання, окрім живлення та мереж? можливо, у них є посилання Fiber-Channel на спільне сховище, KVM - на загальний екран управління - знову ж таки, якщо вони вам потрібні для того, щоб повторити їх однаково.

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

Інші відповіді стосуються технічних аспектів переїзду. Можливо, вам доведеться також розглянути деякі інші речі.

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

Попросіть кваліфіковану особу (або людей) перевірити програми після того, як ви підняли сервери. Попросіть їх зробити перевірку стану безпеки, щоб переконатися, що програми працюють так, як очікувалося.

Після тестування скажіть своїм користувачам, що переміщення закінчено, і повідомте їм, чи є у них проблеми.

Досить складно сказати і прикордонний "занадто широкий" для нашого формату. Найголовніше, що вам потрібно перевірити, це чи потрібно вам перенастроювати мережу будь-яким чином, чи зможе вони продовжувати працювати з тими ж адресами. Навіть якщо вони можуть зберігати однакові адреси, переконайтеся, що вони не налаштовані через DHCP та / або переконайтеся, що сервер DHCP буде доступний у новому місці.

Бічна примітка: Як ви вже заявляли, наявність SQL-сервера та його дзеркала далеко не ідеально. Однак наявність резервних накопичувачів у тому самому місці справді небезпечно. Потрібно мати резервну копію в іншому фізичному місці.

Інші відповіді мають хороші міркування перед переїздом. Однак ви також повинні планувати, як ви організовуєте фактичний хід. Оскільки той факт, що Machine3 є дзеркалом Machine2 , схоже, що тривалість роботи є важливою увагою для баз даних SQL Server 2008 R2. Те, що це дзеркало, надає вам можливість. Причиною існування дзеркала є доступність, коли основний сервер відсутній. Це включає недоступність через технічне обслуговування, яке включає переміщення.

Складіть план:
Ви повинні скласти письмовий план того, як буде здійснюватися переїзд. Можливо, вам доведеться надати цей план або його частини людям, які виконують частину роботи (наприклад, двигуни). Цей план повинен включати всі дії перед переміщенням, власне переміщення та дії після переміщення (наприклад, перевірка функціональності).

Основи переміщення:

1. Перемістіть Machine3 (дзеркало SQL Server). Перевірте повторну синхронізацію.
2. Перемістіть Machine2 : Повна експлуатація.
3. Перемістіть Machine1 : Почніть функціонувати.

Більш детальний опис ходу:

Нижче наведено два способи (Шлях А і В) використання Machine3 для тестування з'єднань для Machine1 та / або Machine2 . Вам слід використовувати лише один метод. Який спосіб зробити це, або навіть якщо використовувати будь-який, залежить від інформації, яка не міститься у запитанні (наприклад, фізичне розділення кінцевих місць машин, фізичний розмір машин, довжина мережевих / силових шнурів, наявність розширень для таких же, схожість конфігурацій мережевих портів, потреби в режимі безперервного часу тощо). Використання Machine3 для тестування цих з'єднань потенційно дозволяє збільшити час роботи для Machine2 , але особливо для Machine1 , який не має дзеркала. Можна вибрати будь-який метод, або жоден.

1. Перемістіть машину3 спочатку.

   • Залиште MACHINE1 і machine2 на місці зараз.
   • Завантажте машину3 , а потім вимкніть її
   • Отримайте Machine3 повністю переїхавши на нове місце.
   • [Шлях B: Не використовується, якщо ви збираєтесь використовувати необов'язковий крок №2.] Якщо мережеві та конфігураційні пристрої для всіх машин однакові: Поставте Machine3 там, де Machine1 планується закінчити, використовуючи з'єднання, призначені для Machine1 .
   • Завантажте машину3 і виберіть її. У новому місці переконайтесь, що воно працює нормально як дзеркало машини2 . Це забезпечить фізичну перевірку того, що конфігурація всіх питань (живлення, мережа тощо) функціональна в новому місці.
   • Вирішіть будь-які проблеми, що виникають.
   • Переконайтесь, що Machine3 повністю синхронізувався з Machine2 до початку роботи.

2. Шлях A: (необов’язково):

   • Використовуйте Machine3 для перевірки всіх об'єктів , призначених для machine2 і MACHINE1 .
   • Вимкніть Machine3 та перейдіть / перейдіть до використання положення / з'єднань для Machine2 (перевірте повторну синхронізацію), а потім Machine1 (перевірте повторну синхронізацію). Якщо ви планували зробити це, то Machine3 повинні були спочатку створені з сполуками , призначених для кінцевого використання MACHINE1 або machine2 , так що ви не встановите його першим в кінці кінців місце для Machine3 , а потім змінити його 3 рази, але тільки 2, починаючи з нього, використовуючи засоби однієї з інших машин.
   • Переконайтесь, що Machine3 повністю синхронізувався з Machine2 до початку роботи.

3. Перемістіть машину2 .

   • Ваша практика з Machine3 повинна зробити це набагато більш гладким.
   • Створіть резервну копію Machine2 , а потім вимкніть її
   • Перенесіть Machine2 на нове місце; зробити всі з'єднання
   • Вирішіть будь-які проблеми, що виникають.
   • Переконайтесь, що Machine2 повністю синхронізувався з Machine3 до початку роботи.

4. [Шлях B: Не потрібен, якщо ви перевірили всі з'єднання з Machine3 на необов'язковому кроці №2] Якщо зараз є Machine3, де Machine1 має закінчитися:

   • Вимкніть Machine3 .
   • Перемістіть його туди, де планується в кінцевому підсумку (з місця, де ви плануєте розташувати Machine1 ).
   • Вирішіть будь-які проблеми, що виникають.
   • Переконайтесь, що Machine3 повністю синхронізувався з Machine2 до початку роботи.

5. Перемістіть машину1 .

   • Переїхавши Обидва machine2 і Machine3 (і , сподіваюся , протестували фактичні з'єднання Machine1 буде використовувати при наявності Machine3 використовувати їх тимчасово), це повинно бути гладким з ходів.
   • Зробіть резервну копію Machine1 , а потім вимкніть її
   • Перенести Machine1 на нове місце; зробити всі з'єднання
   • Вирішіть будь-які проблеми, що виникають.
   • Якщо щось не в порядку з об'єктами в положенні, яке Machine1 повинен зайняти, у вас є можливість використовувати засоби, де зараз знаходиться Machine3 . Сподіваємось, ви вже змогли протестувати всі об'єкти, що знаходяться в положенні Machine1 , використовуючи його Machine3 протягом певного часу (Шлях А або Шлях Б).

Якщо будь-який з IP-адрес серверів зміниться, і з'єднання будуть встановлені у вікні SQL за допомогою роздільної здатності DNS, тоді вам потрібно буде запланувати зміну записів DNS одночасно з переміщенням.

Що слід знати про програмне забезпечення та бази даних інтранет:

• Чи підключається програмне забезпечення інтранет до SQL Server через IP, NetBIOS або DNS?
• Чи мають облікові записи користувачів SQL Server, які використовуються програмним забезпеченням інтранет, автентифікацію обмежено трафіком, що надходить з IP-адреси?
• Чи мають доступ співробітники вашої компанії безпосередньо до SQL Server з будь-яких електронних таблиць чи інструментів звітування, якщо так, то як вони визначають DSN?

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

Використовуйте ваші сервери "Відновлення після катастрофи". Переключіться на них, щоб обробляти навантаження під час переміщення виробничих серверів. Завдяки правильно налаштованому обладнанням ДР, ви можете рухатись посеред дня, не бачачи великих простоїв (до 15 хвилин). Оскільки сервери відновлення після аварій повинні бути налаштовані так само, як і виробничі сервери. Якщо у вас немає обладнання ДР, настійно рекомендую придбати їх.

Подумайте про це так: поки ваш корвет налаштовується, використовуйте свій мінівен, щоб пройти день.

Я не думаю, що вже згадувалося, це фізична безпека нового дому серверів. Для чого використовувалася кімната раніше і хто має ключі від неї? Чи є достатня безпека (сигналізація, камери тощо).

Деякі міркування на додаток до інших відповідей:

• Чи пов’язані додатки з іншими, наприклад, нічний обмін даними по файлах або за допомогою веб-служб? Які наслідки, коли програми недоступні? Чи можуть відповідні програми впоратися з цим чи вони не працюють або навіть дають неправильні результати через брак інформації у ваших програмах?

• Чи час простою прийнятний для ваших користувачів, компанії чи навіть клієнтів? Як довго це може бути?

• Я думаю, що це гарна ідея мати план відката. Ви можете використовувати його у випадку проблеми, яку неможливо швидко вирішити, наприклад, проблема з мережею. Можливо, вам потрібно буде тримати доступний механізм для повернення обладнання.

• Чи ваші додатки призводять до великого мережевого трафіку і чи потрібно до цього готуватися до мережі (можливо, це набагато більше навряд чи проблема, ніж проблеми з адресами та брандмауерами)? Якщо у вас є додатки в режимі реального часу (наприклад, програмне забезпечення для відеоконференцій), затримки будуть важливими.

• Сервери повинні вміститися в серверну стійку, якщо у вас є.