Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

Ralex. We do the work.
На рынке с 1999го года. Средняя ценовая категория. Ориентация на эффективность решений.
Ознакомтесь с нашим портфолио
Узнайте больше о услугах
Свяжитесь с нами:
E-mail: [email protected]
Tel: (044) 587 - 84 - 78
Custom web design & дизайн и разработка сайта "под ключ"
Креативный, эффективный дизайн. Система управления сайтом (СУС).
Custom flexible разработка систем электронной коммерции
Система e-commerce разрабатывается под индивидуальные потребности. Гибкая функциональность.
Search Engine Optimzation & оптимизация под поисковые системы (SEO)
Постоянная оптимизация и мониторинг сайта в поисковых системах. Достигаем результата быстро и эффективно
Custom logo design & дизайн логотипа и фирменного стиля
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.
профессиональная рекламная фотография
креативно, смело, качественно
Custom logo design & рекламный креатив. дизайн рекламы
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.

Відновлення після збою за допомогою Dfs

  1. Готовність до збою
  2. Короткий огляд Dfs
  3. планування реплікації
  4. Проект реплікації Dfs
  5. Конфігурація кореня Dfs
  6. Додавання надмірності в Dfs
  7. Поради і застереження в роботі з Dfs

Наша взаимовыгодная связь https://banwar.org/

Що таке катастрофа з точки зору планування відновлення після збою? Відповідь здається очевидним, але можна зіткнутися з серйозними труднощами, намагаючись визначити всі, що входить в поняття катастрофи. Легко визначити поняття «стихійне лихо» на прикладі землетрусів, пожеж та повеней, але збій може бути викликаний і незвичайними причинами. Мені, жителю Вашингтона, доводилося зустрічати десятки людей, ділова активність яких в останні два роки переривалася карантинами і евакуаціями через загрозу терористичних актів, застосування біологічної зброї і дій кримінального характеру. Очевидно, подібного роду обставини більшістю ІТ-адміністраторів при підготовці до відновлення після збою, цілком ймовірно, враховуватися не будуть.

Після розмов з людьми, які безпосередньо стикалися з цими ситуаціями, я сформулював для себе наступне визначення катастрофи: катастрофа - це будь-яка подія, яка позбавляє користувачів їх ділових даних на неприйнятно тривалий час (іноді назавжди) і в результаті піддає ризику життєздатність організації. Не стану сперечатися, що моє визначення, можливо, занадто широке - навіть така проста ситуація, як несправність жорсткого диска, може під нього підійти. Однак в залежності від кількості та типу порушених таким чином даних і вірогідності відновлення необхідної інформації в прийнятний час (якщо це взагалі можливо) деякі організації цілком могли б розглядати вихід з ладу жорсткого диска як катастрофу. Для того щоб розробити оптимальні рішення, що забезпечують відновлення після збою, слід ставитися до планування відновлення як до способу мінімізації часу, протягом якого користувачі відокремлені від потрібних даних, незалежно від обставин. Розглянемо приклад ситуації глобального збою і спробуємо встановити, яку роль може зіграти служба розподіленого зберігання файлів Microsoft Dfs в плануванні відновлення і мінімізації часу, який доведеться витратити на підключення користувачів до певних типів даних.

Готовність до збою

Уявімо собі, що нам належить розробити план відновлення після збою, який міг би використовуватися в разі катастрофи. Наша компанія має офіси в Нью-Йорку і Лондоні, а інфраструктура, що зв'язує ці точки, складається з серверів, настільних систем, маршрутизаторів і концентраторів. Ця інфраструктура є основою для роботи багатьох програм, в тому числі додатки загального користування (email), вертикального бізнес-додатки (LOB), додатки планування ресурсів підприємства (ERP), додатки для бази даних і файлового сховища. Припустимо, що за останню декаду терористи обрали собі за мету обидва офіси і що начальник готує нас до гіршого - повної втрати одного з офісів на невизначений час.

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

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

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

Короткий огляд Dfs

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

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

Така функціональність забезпечується роботою служби File Replication Service (FRS). FRS вбудована в Window 2000 і не вимагає ніякого налаштування (Dfs - єдиний з розглянутих компонентів, який слід налаштовувати). Розберемо приклад конфігурації Dfs, придатної для цілей відновлення після збою.

планування реплікації

Припустимо, що у нас є по кілька серверів в обох офісах - в Лондоні і в Нью-Йорку - і вирішено реплицировать файли даних спільного використання (наприклад, документи, таблиці, презентації Microsoft PowerPoint, маркетингові матеріали) з одного офісу в інший. Ці дані розкидані по декількох серверах на кожному сайті, і потрібно створити резервну копію даних лондонського офісу на одному сервері в Нью-Йорку і навпаки.

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

Потім слід оцінити пропускну здатність, необхідну для підтримки реплікації між вузлами. Наприклад, якщо зв'язок між офісами здійснюється по каналу T1, це означає, що є смуга пропускання в 1,5 Мбіт / с для передачі даних з одного вузла в інший. Необхідно визначити, яка частина цієї смуги пропускання використовується в процесі звичайної зв'язку між вузлами, - швидше за все, цю інформацію зможуть надати провайдери WAN. Якщо дана інформація в готовому вигляді недоступна, можна задіяти інструмент вилучення даних по протоколу SNMP, такий як Multi Router Traffic Grapher (MRTG), щоб простежити за використанням пропускної спроможності. Який би спосіб не був обраний, слід відняти використовується кількість смуги пропускання із загального доступного кількості. У нашому прикладі будемо вважати, що половина смуги пропускання між нью-йоркським і лондонським офісами вже використовується, в результаті чого залишається вільною частина смуги в 750 Мбіт / с.

Нарешті, слід з'ясувати, як багато призначених для користувача даних в кожному офісі змінюється протягом дня. Dfs реплицирует зміни на файловому рівні, тому кожен раз, коли хтось вносить зміни в підлягає реплікації презентацію PowerPoint розміром 20 Мбайт, Dfs буде пересилати цілком файл 20 Мбайт через WAN, і це буде частиною процесу реплікації. Очевидно, реплікація даних подібним чином може сильно навантажити мережу.

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

Після того як ми дізнаємося, скільки даних (в байтах) змінюється користувачами протягом дня, потрібно помножити цю кількість на 8, щоб висловити отримане число в бітах. Припустимо, наприклад, що наша вигадана організація протягом одного дня модифікує 200 Мбайт даних. Якщо помножити 200 Мбайт на 8, то вийде, що необхідно реплицировать 1,6 млрд. Біт даних. Розділимо це число на загальну кількість доступної смуги пропускання і знайдемо число секунд, яке займе трафік реплікації Dfs в мережі на даний день (в нашому прикладі це 2133 секунди в день). З огляду на, що день складається з 86 400 секунд, мабуть, можна вважати, що при розрахунковому часу Dfs-реплікації цілком доцільно відправляти дані по каналу T1, навіть якщо кілька вузлів оновлюються в один і той же час (модель реплікації FRS має кілька основних реплік і може обробляти кілька вузлів одночасно).

Можна підвищити якість розрахунків, використовуючи інтервал менше 24 годин для визначення кількості даних, мінливих за день, і кількості секунд, що складають цей проміжок часу. Ще потрібно пам'ятати, що ми не беремо до уваги передачу службових даних - заголовків пакетів, які можуть істотно збільшувати загальна кількість переданих даних, зазвичай 56 байт на пакет. Оскільки трафік реплікації Dfs між двома містами буде найбільш помітний в години максимального ділової активності, можна вважати, що робочий день, що охоплює нью-йоркський і лондонський офіси, триває 13 годин (звичайний 8-годинний день плюс 5-годинна різниця). Тепер, коли є вільний дисковий простір і смуга пропускання, призначені для реплікації, слід перейти до планування і реалізації плану.

Проект реплікації Dfs

У стандартній установці Windows 2000 без Dfs операційна система зазвичай зберігає призначені для користувача файли в папках на сервері, і ці папки є папками загального доступу для кінцевих користувачів. Для того щоб працювати з файлами в папках загального доступу, кінцеві користувачі підключаються до цих мережевих ресурсів або безпосередньо, або за допомогою призначення букв для мережевих дисків. Підключення до мережевих ресурсів спрощує пошук даних в мережі для кінцевих користувачів і складається з чотирьох функціональних рівнів, починаючи з рівня користувача і його ресурсу, потім йде рівень папки, рівень файлу і, нарешті, рівень фізичного диска. Залежно від того, як планується проектувати інфраструктуру Dfs, можливо, знадобиться один або два додаткових рівня - обов'язковий рівень кореня Dfs (рис. 1) і необов'язковий рівень зв'язків Dfs (рис. 2).

Кореневої рівень Dfs подібний корені жорсткого диска - у кожного диска повинен бути корінь, і структура Dfs не виняток. Коли створюється структура Dfs, слід виділити один або кілька ресурсів мережі, які будуть виступати в ролі кореня Dfs. Щоб мати певний запас, можна створити кореневі ресурси на декількох серверах в рамках однієї структури Dfs. Розглянемо процес реалізації кореневої структури Dfs, використовуючи тестову лабораторію в домені Active Directory (AD) netarchitect.local, з реплікацією даних між двома серверами: ARCHITECT10 і DMZSERVER.

Конфігурація кореня Dfs

У Windows 2000 процес створення кореня Dfs починається з запуску оснащення Microsoft Management Console (MMC) Distributed File System через Start, Programs, Administrative Tools. Слід натиснути правою кнопкою по Distributed File System в правій панелі оснастки, потім вибрати New Dfs Root, щоб запустити майстер конфігурації. Для початку потрібно вирішити, який корінь Dfs потрібно створити: доменний або одиночний. Оскільки ми визначаємо корінь Dfs для підтримки реплікації між вузлами, нам необхідний доменний корінь Dfs.

Потім слід вирішити, в якому домені AD потрібно розмістити створюваний корінь Dfs. Потрібно вибрати домен, який більше підходить для конкретної ситуації, як показано на рис. 3. Доменне ім'я, вибирається нами на даному етапі, - це те ім'я, яке кінцеві користувачі будуть застосовувати для підключення до кореневої структурі Dfs. Наприклад, коли користувачі захочуть підключитися до кореню Dfs в нашому випадку, вони будуть звертатися до etarchitect.localDfs root name, а не підключатися безпосередньо до якого-небудь сервера.

Після вибору домену слід визначити головний сервер для кореня Dfs, потім вибрати загальний ресурс, який буде використовуватися в подальшому. Якщо ресурс не був створений на самому початку, можна зробити це пізніше. Ресурс повинен бути прив'язаний до папки на диску NTFS, оскільки FRS використовує систему протоколювання NTFS 5.0 (NTFS 5) для відстеження моменту зміни файлу. Для нашого прикладу я створив ресурс з ім'ям netarchitect-dfsroot на сервері ARCHITECT10. Можна задіяти будь-яке ім'я, але використання описових імен для ресурсів спрощує роботу з папками, ресурсами і репліками, коли їх багато.

Заключний крок в конфігурації кореня Dfs - привласнення йому імені (рис. 4). Подібно імені домена, користувачі будуть задіяти це ім'я кореня Dfs, щоб підключитися до структури Dfs. Саме тому я вважаю за краще використовувати ім'я, яке описує функцію ресурсу (наприклад, ReplicatedFiles - реплицируемой файли, SyncFiles - синхронізуються файли).

По завершенні цього кроку слід протестувати новий корінь Dfs з якою-небудь робочої станції, підключаючись до UNC-ім'я domainnameDfsrootname, яке було визначено в процесі створення кореня Dfs (наприклад, etarchitect.localSyncFiles). Робоча станція отримає дані про Dfs з AD, а потім знайде лежать нижче кореня загальні ресурси.

Додавання надмірності в Dfs

На даному етапі у нас є структура кореня Dfs, але коріння не продубльований. Тому наступний крок - створення репліки кореня Dfs натисканням правої кнопки миші Distributed File System в лівій панелі оснащення Distributed File System. Необхідно вибрати в контекстному меню пункт New Root Replica, щоб запустити майстер Dfs Root Wizard. Спочатку слід вибрати комп'ютер, який планується призначити головним комп'ютером для копії кореня Dfs, в нашому прикладі це DMZSERVER. Потім потрібно вибрати загальний ресурс, який був визначений перед запуском майстра; в нашому прикладі це netarchitect-dfsroot.

Після того як вказано загальний ресурс для кореня Dfs на другому сервері, слід налаштувати реплікації між обома ресурсами. За замовчуванням Dfs не налаштовувати реплікацію даних автоматично, тому її доведеться включити. Потрібно натиснути правою кнопкою по створеному корені Dfs, потім вибрати Replication Policy з контекстного меню, щоб відкрити діалогове вікно Replication Policy, показане на рис. 5. Слід клацнути Enable, щоб включити реплікацію для кожного ресурсу, а потім визначити, який ресурс буде головним під час першої реплікації. Виберіть Set Master для цього ресурсу. Після виконання перерахованих кроків Windows 2000 буде реплицировать дані між цими ресурсами і утримувати їх синхронізованими. Як тільки відбудеться первісна реплікація, різниця між первинним ресурсом та іншими ресурсами зникне.

Закінчення настройки реплікації Dfs для конкретної середовища залежить від того, як передбачається реалізувати Dfs. В даний момент вже можна переносити каталоги, підкаталоги і файли в корінь Dfs, а Windows 2000 буде автоматично синхронізувати дані між усіма ресурсами кореня Dfs. Точніше кажучи, можна цілком задіяти деревоподібну структуру каталогів, щоб все критично важливі файли даних розташовувалися десь всередині структури Dfs. Тоді можна бути впевненим, що в разі глобального збою (катастрофи) ця інформація буде реплицирована і доступна з інших офісів організації.

Можна піти ще далі і створити посилання Dfs всередині структури Dfs. Посилання Dfs з'являються перед кінцевими користувачами як папки в рамках структури Dfs, але реально вони представляють собою нові ресурси, певні всередині структури Dfs (окремо від ресурсів, які використовувалися для визначення кореня Dfs; див. Рис. 2). Посилання Dfs особливо корисні, коли є різні типи даних, які вже існують на декількох серверах, і потрібно консолідувати цю інформацію в єдину структуру каталогів з простою навігацією. Для того щоб створити посилання Dfs, потрібно натиснути правою кнопкою по знову певного корені Dfs в лівій панелі оснащення Distributed File System, потім вибрати New Dfs Link для запуску майстра конфігурації. Як і при конфігурації кореня Dfs, майстер попросить вибрати сервери і ресурси, які будуть брати участь в зв'язку, і встановити реплікацію між ресурсами.

Поради і застереження в роботі з Dfs

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

Кроме переміщення файлів Даних з однієї реплікі в іншу, Windows 2000 такоже реплицирует дозволено, Які були візначені в структурі Dfs. Якщо додати або видалити дозвіл на папку або файл в одному місці, Dfs реплицирует ці зміни по всій мережі.

Єдиний елемент, який не підлягає реплікації Dfs, - це блокування файлів, індикатори, за допомогою яких Windows 2000 визначає, чи працює з файлом хто-небудь ще. Це питання важливе і, найімовірніше, він вплине на спосіб формування структури Dfs. Оскільки Dfs НЕ реплицирует блокування файлів, два користувача можуть працювати з одним і тим же файлом одночасно, кожен зі своєю копією. Якщо така ситуація має місце і обидва користувачі зберігають свої зміни в мережі приблизно в один і той же час, спрацьовує правило «перемагає записав останнім» (last-writer-wins). Наприклад, зміни, зроблені одним користувачем, можуть бути записані на диск і синхронізовані, а потім майже відразу ж переписані змінами, збереженими іншим користувачем. Щоб уникнути подібної ситуації, я зазвичай раджу користувачам завжди розглядати синхронізовані репліки тільки як резервні копії, т. Е. Ресурси, до яких користувачі не повинні мати прямого доступу.

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

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

Оскільки реплікація Dfs запускається при зміні файлу, Dfs погано працює з файлами баз даних, які завжди відкриті, - раз з файлами баз даних ніколи не виконуються операції закриття, ці дані ніколи не синхронізовані. В результаті Dfs не зможе реплицировать бази даних Microsoft SQL Server і Microsoft Exchange Server. Важливо пам'ятати про те, що реплікація Dfs подібна створення дзеркального образу диска (т. Е. Система реплицирует ті дані, які має). В результаті, якщо робочу станцію користувача вражає вірус, який пошкоджує всі файли типу .doc, а користувачі модифікують ці файли, Dfs буде реплицировать пошкоджені файли до тих пір, поки вони знаходяться в структурі Dfs. Цей приклад показує, чому традиційне резервне копіювання все ще необхідно. І нарешті, за замовчуванням Dfs НЕ реплицирует певні типи файлів: .bak, .tmp і будь-які файли, імена яких починаються з тильди (~).

Дуглас Тумбс - редактор Windows & .NET Magazine. Має сертифікати MCSE, Compaq ASE і Novell CNA. З ним можна зв'язатися по електронній пошті за адресою: [email protected].

Категории
  • Биология
  • Математика
  • Краеведению
  • Лечебная
  • Наука
  • Физике
  • Природоведение
  • Информатика
  • Новости

  • Новости
    https://banwar.org/
    Наша взаимовыгодная связь https://banwar.org/. Запустив новый сайт, "Пари Матч" обещает своим клиентам незабываемый опыт и возможность выиграть крупные суммы.


    Наши клиенты
    Клиенты

    Быстрая связь

    Тел.: (044) 587-84-78
    E-mail: [email protected]

    Имя:
    E-mail:
    Телефон:
    Вопрос\Комментарий: