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

Предназначение и характеристики на DFS

DFS разпределена файлова система (Разпределени Файлова система ) се появи като
стандартен компонент обратно в Win2k. Целта му е да улесни управлението, достъпа и
търсене на данни в мрежата. За да направите това, файлови ресурси, разположени на различни
компютрите са комбинирани в едно логическо пространство от имена. потребител,
вместо да запомня имената на всички мрежови споделени ресурси (Universal Naming
Конвенция, UNC) като \\ Сървър \ Папка ще се отнася до едно пространство
UNC-име, което обединява всички сървъри и споделени ресурси в мрежата. И на какво
исканият файл се намира конкретно на компютъра, това вече е проблем DFS, потребител
няма нужда да се притеснявате за действителното местоположение на файла. Когато клиент се обади, той
просто се хвърля в директорията, от която се нуждае. На мястото на източника към който
обозначава връзка, може да бъде всяка операционна система, към чиито ресурси
може да бъде достъпен чрез UNC (Windows, Linux, xBSD, NetWare). Физически
обекти, свързани с връзки към DFSсе наричат ​​цел обекти(цели) или
реплики(реплики).

Но удобството за потребителите и администраторите е далеч не най-важното от
Основни предимства на DFS... Въпросът е, че с едно логично име може да има
има няколко споделени ресурса, които съхраняват идентична информация.
Такъв набор от алтернативни споделени ресурси, свързани с едно логическо име
DFSсе нарича набор от реплика. И ако споделените ресурси са в едно
коренно пространство на домейна DFSи се намират на Win2k или Win2k3 сървъри,
възможно е да се настрои автоматично синхронизиране на информацията между тях.
Потребителят, който се е свързал DFS, обикновено пренасочва към най-близката реплика и
ако не е достъпен, ще бъде пренасочен към алтернативен ресурс... За
намаляване на натоварването на сървъра DFSот страна на клиента данните се кешират, т.е
с чест достъп до един и същ ресурс, всяка заявка към DFSне
произведени. По този начин автоматичната архивиране на важна информация,
осъзнах в DFS, също така увеличава отказоустойчивостта на цялата система (изход
един сървър или дисково устройствоняма да повлияе на потребителското изживяване).
Въпреки че трябва да се помни, че DFSне е проектиран да работи с често актуализирани
данни, и особено за онези случаи, когато файлът може да бъде едновременно актуализиран в
на няколко места (в DFSверсията на файла остава там, където е последната
промени).

В изпълнение DFS в Win2kможе да се побере само едно пространство от имена,
може вече да има няколко от тях в Win2k3. Win2k3 R2 представя нова версиятова
системи - DFS пространства от имена, в който вече са решени много въпроси. За репликация
данни в Win2k3 SP1 и SP2 отговаря FRS (Сървър за репликация на файлове), в Win2k3 R2 -
DFS репликациян. Основната им разлика е, че в FRSнай-малкият
обектът, който трябва да бъде репликиран, е файл в DFS репликацияизползван от
по-модерна технология RDC (Дистанционна диференциална компресия), който може
копирайте само променените части на файла и функцията за кръстосани файлове RDCпо-малък
зарежда канала при копиране на нови файлове. Така че използвайки DFS
също така намалява натоварването на мрежата, което е особено важно за отдалечени офиси с
недостатъчна честотна лента. В услуга DFSне
допълнителни мерки за сигурност. Когато се позовава на целите
проверяват се само разрешенията на файловата система и разрешенията, зададени за тях
обекти на разрешения в директорията Active Directory.

Тези различни корени

Начална точка за всички имена на дървета DFSслужи като корен на разпределеното
файлова система. Всъщност коренът е някакъв споделен ресурс, намиращ се на
сървър, всички останали DFS системни логически именаще се свърже като
следващото йерархично ниво. Корени в DFSможе да бъде от два вида, всеки
се различава по методите и възможностите за съхранение на данни. Изолиран (самостоятелен)
корен ( Самостоятелен DFS) не е свързан с Active Directory и всички връзки към мрежата
ресурсите се съхраняват в регистъра на самия сървър DFS... Този корен не използва
DFS
Репликацият.е. не предполага дублиране на информация за други ресурси,
и следователно не осигурява отказоустойчивост. В случай на неуспех DFS сървър
цялата йерархия става недостъпна, въпреки че потребителите имат достъп
ресурси директно. Между другото, няколко самостоятелни DFS сървъраможе да работи
в клъстера, така че този проблем може да бъде разрешен. Ако сървърът DFSе
член на домейна, се използва коренът на домейна ( DFS, базиран на домейн). С тази
опция, можете да свържете множество реплики и да използвате DFS репликацияза
репликация както на самия корен, така и на връзките DFS... Ако в DFS, базиран на домейнкорени
се намират на компютри, работещи с Win2k и Win2k3, тогава такъв root
Наречен " DFS домейн в смесен режим".

С домейн DFSцялата информация за пространството от имена е в контролера
домейна, до който сървърът периодично осъществява достъп DFS... Предвид синхронизацията
между DFSв домейна, което става по-сложно с всяка промяна
структури, тези заявки могат да бъдат пречка в системата, така че в този случай
има и някои ограничения. Така че в Win2k имаше ограничение от 16
корени за едно и също пространство от имена. В Win2k3 това ограничение е премахнато, т.к
сървър DFSвече има достъп до всеки DC, не само до PDC емулатора.
Второто ограничение на корените на домейна се дължи на факта, че цялата структура се съхранява в
специален обект, който също трябва да бъде дублиран на всички DC за всеки
най-малката промяна в структурата DFS... Документацията препоръчва ограничаване
максималният размер на обект е 5 MB, което приблизително съответства на 5000
връзки (директории). Тази стойност зависи от много параметри, дължината на името
връзки, наличие и размер на коментари, които също се съхраняват в този обект.
Но средно DFSрядко надвишава 50-100 връзки, а след първоначалната
настройки, той остава предимно статичен, което означава, че често не се дублира
ще бъде и тези ограничения просто няма да бъдат постигнати. Между другото, в бъдеще
Windows 2008ограничението от 5000 връзки вече е премахнато, но за това всички сървъри
трябва да работи Longhorn. За Препоръчва се самостоятелен DFS
лимит на връзкатас порядък по-високо и е 50 000 връзки.

DFS конфигурация

Например, нека настроим DFSна компютър, работещ с Win2k3 със SP2, всичко
настройките в SP1 са подобни. В настройките DFS R2 и Win2k имат някои
различия, но не толкова глобални, че да не го разберете сами. Всичко
разпределената файлова система се управлява централно от
помогне фиксиращ MMC "DFS разпределена файлова система„което можеш
обадете се в раздела "Административни инструменти" на контролния панел на Windows. С нейна помощ
можете да създавате и изтривате roots, да се свързвате с всякакви roots DFS... Удобно, в
множество корени могат да бъдат показани в един раздел DFS... Ако коренът работи в " Смесени
режим на домейн DFS", тоест, когато реплики и корени DFSразположени на компютрите
управлявани от различни Версии на Windows, управление DFSтрябва да се свърши с
компютър с Win2k3. Като алтернатива можете да инсталирате пакета Пакет инструменти за администриране на Win2k3(adminpak.msi), който е свободно достъпен на адрес
уебсайт на корпорацията. В този случай компютрите с
WinXP. Информация за този пакет можете да намерите на

support.microsoft.com/kb/304718. Освен това за работа с DFSможете също
използвайте помощните програми на командния ред dfscmd.exe и dfsutil.exe. Последният има
повече функции, но не е включено в операционната система по подразбиране,
за да го използвате, трябва да инсталирате пакета Win2k3 Support Tools. Обратен
Моля, имайте предвид, че за успешната инсталация на Инструменти за поддръжка, трябва да изтеглите два файла:
suptools.msi и support.cab.

За да създадете нов корен, извикайте добавката, щракнете върху заглавието и влезте
контекстно менюизберете "Създаване на root" (Нов корен), като опция можете
изберете подобен елемент в менюто "Действие". Появява се съветникът за ново създаване.
root (New Root Wizard), следвайте неговите подкани. Във втората стъпка изберете типа
на създадения корен (домейн или изолиран), посочете хост домейна и
сървър. След като проверите връзката с избрания сървър, въведете името на root. Обратен
обърнете внимание как ще изглежда UNC пътя към новия корен, по подразбиране \\ server \ nameshare.
Тъй като в момента общ указателне съществува, в следващата стъпка ви трябва
изберете локална директория, която да се използва като споделена директория. Това
директорията не съдържа реални данни, тя ще съдържа връзки, сочещи
физическото местоположение на данните. Помощникът създава ресурси, които позволяват четене и
изпълнение за членове на групата Потребители. Коригирайте, ако е необходимо
разрешения. Сега натискаме бутона Finish, новият корен ще се появи в прозореца на конзолата.
Ако сървърът работи с Win2k3, по подобен начин създайте и
други корени. Използване на командата Проверка на състоянието, извикана от
конзолното меню или менюто за бърз достъп, можете да проверите състоянието на репликата. състояние
ще бъде посочен в едноименната колона и до името ще се появи кръг със знак.
Ако е зелено, значи всичко е наред. За да проверите, можете да отидете на
посочен UNC или използвайте на локален компютъркомандата "net share" или
"Net view computer_name" от дистанционното. Dfsutil / Root: \\ сървър \ споделяне / команда Преглед
ще покаже DFS информация.

> dfsutil /Root:\\server.com\first / View
DFS Utility версия 5.2 (построена на 5.2.3790.3959)
Корен на домейн с 0 връзки
Root Име = "\\ SERVER \ first" Comment = "first Root" State = "1" Timeout = "300"
Целеви сървър = "GRINDERS" Папка = "първо" състояние = "2"

След като коренът е създаден, той може да бъде публикуван в Active Directory. За това в
изберете Свойства от контекстното меню, отидете на раздела Публикуване и
поставете отметка в квадратчето „Публикуване на този корен в Active Directory“. домейн
корените се публикуват автоматично и безпроблемно.

Изграждане на връзки

След като коренът бъде създаден, можете да започнете да свързвате споделяния. Защо е
изберете елемента Нова връзка от контекстното меню. В прозореца, който се показва
"Нова връзка", в полето "Име на връзката" въведете името на връзката, под която ще бъде
наличен в DFS, след това точно под UNC пътя към целевата директория (вече трябва
съществуват). За да търсите споделени ресурси, можете леко да използвате бутона Преглед
по-долу можете да промените времето за кеширане на тази връзка за клиенти DFS(по подразбиране
1800 секунди). Когато приключите, натиснете бутона OK. Командата dfsutil / view трябва
показва състоянието на всички свързани връзки и техните свойства. Ако мрежата работи
множество сървъри, възможно е да се добави реплика, сочеща към
алтернативна връзка. Създава се реплика на корена или отделен обект
по същия начин, само в първия случай, в контекстното меню изберете елемента „Създаване
root целева папка ", а във втората -" Създаване на папка ".

Споделените ресурси, които ще бъдат репликирани, трябва
разположени в дялове с файловата система NTFS на компютри, работещи под
изпълняващи сървърни версии на Windows от 2000 г. (по-добри от 2003 г.). В „Пътят към
целева споделена папка "на прозореца, който се показва, въведете или използвайте бутона Преглед
ние посочваме споделен ресурс, разположен на друг компютър. В случай, че
за синхронизиране на информация между тези ресурси се планира да се използва
алтернативни програми (или синхронизацията ще се извърши ръчно),
премахнете отметката от квадратчето Добавяне на тази целева папка към набора за репликация.
цел към набора за репликация). Щракнете върху OK и се появява съветникът за настройка
репликация (Configure Replication Wizard), която ще ви помогне да изберете
главна реплика и топология на репликация. На първата стъпка указваме директорията, която
ще се използва като основна цел, цялата информация от това
след това директорията ще бъде копирана в друга папка. Последният трябва да е празен,
ако съдържа файлове, те ще бъдат копирани във временна директория и след това
премахнати. Ако даден дял по някаква причина не е подходящ за репликация
(например, не се намира на NTFS дял), той ще бъде маркиран с червен кръст,
когато се опитате да преминете към следващата стъпка, съветникът ще ви предложи да посочите различна връзка или
завърши работата.

С натискане на бутон Междинно съхранение" (Постановка папка) може да се промени
местоположението на директорията, която ще се използва за временно съхранение
репликирани данни. По подразбиране тази директория се намира в раздел, различен от
от този, на който се свързва дялът с DFS... Допълнителен майстор
ви подканва да изберете топология на репликация. Ще трябва да посочите един от
следните опции:

• Пръстен- всички реплики обменят информация с две съседни;
• Звезда (главина и спици)- е посочена основната връзка, от която ще
  обмен на информация всички други реплики;
• Пълна мрежа- всички реплики се разменят помежду си;
• Персонализиран- по-късно администраторът самостоятелно ще конфигурира репликацията
  за всяка двойка сървъри.

Топологията на пръстена е зададена по подразбиране и е подходяща за повечето
случаи. В идеалния случай избраната топология на репликация трябва да съответства на схемата
мрежи. Например, ако има централен офис, където се намират основните ресурси,
и многобройни клонове се свързват с тях, ако е необходимо, след това в това
В случай, че схемата на Звезда е по-подходяща. Ако нито една от предварителните настройки не работи,
трябва да се обърнете към елемента Специално.

След създаване на реплика за връзката, съответната икона в прозореца на добавката
ще се промени. Два нови елемента също ще се появят в контекстното меню: Покажи / Скрий
състояние на репликация и Спиране на репликацията. Полето за статус на репликация може да бъде
един от трите резултата. Ако процесът на репликация завърши нормално, иконите
ще има зелени знамена. Червен кръст върху иконата на реплика ще покаже, че е в ход.
моментът е недостъпен, в полето Статус подписът ще се промени на Офлайн. Ако в
само някои реплики са недостъпни за проверената връзка, в иконата ще се появи жълта икона
Удивителен знак.

Преди да изтриете една от алтернативните реплики, първо трябва да откажете
репликация. Когато репликацията се възобнови, ще бъдете посрещнати от същия господар. Ако
сървърът е домейн контролер, заедно с всички DFS даннище
също така репликирайте съдържанието на тома SYSVOL. Следователно трябва да се помни, че дотогава,
докато всички реплики бъдат напълно репликирани, започнете всички промени в
конфигурация DFSмного рисковано, може да наруши работата на всички
домейн.

Ако избраната опция за топология на репликация по някаква причина не успее
Приближавайки се, топологията на репликация може лесно да бъде променена по-късно чрез избиране на прозореца
свойства на съответната връзка и щракнете върху раздела Репликация. Тук са
няколко Все още полезни настройки... По подразбиране репликацията работи непрекъснато,
като щракнете върху бутона График, можете да промените графика за репликация за всички
връзки. По-долу са филтрите за файлове и подпапки, които не са
ще бъдат репликирани. За да направите това, щракнете върху Промяна и въведете файлови шаблони или
поддиректории.

За да принудите репликация на информация, съхранявана на конкретен сървър,
можете да използвате помощната програма NtfrsUtl.exe, която е включена в пакета
Инструменти за поддръжка... Командата е проста: "ntfrsutl poll / now server.com". Да видиш
задайте интервали от време за репликация,
въведете "ntfrsutl анкета". Всички настройки са достъпни с командата „ntfrsutl sets
server.com“.

В прозореца със свойства на дял, представен в услуга DFS, ще има още
един раздел - DFS... Като го отвори, потребителят може да види с кое общ
папки са свързани с тази връзка, проверете състоянието на репликата, изберете активната
репликата, към която ще бъде пренасочена първа.

Администраторът трябва да проверява дневника по-често за контрол.
"Администриране - Преглед на събития - Услуга за репликация на файлове", където можете
намерете информация за всички събития, случващи се с услугата FRS.

В момента, в контекста на нарастването на информацията, има проблеми със съхраняването и обработката на много големи данни. Следователно тези данни се обработват на няколко сървъра едновременно, които образуват клъстери. За да се опрости работата с данни в клъстери, се разработват разпределени файлови системи. Ще разгледаме по-отблизо пример за разпределена файлова система. Google файлова системаизползвани от компанията Google... (Статията всъщност е свободен и съкратен превод на оригиналната статия).

GFSе може би най-известната разпределена файлова система. Надеждното, мащабируемо съхранение на данни е от съществено значение за всяко приложение, работещо с толкова голямо количество данни като всички документи в Интернет. GFSе основната платформа за съхранение на информация в Google. GFSе голяма разпределена файлова система, способна да съхранява и обработва огромни количества информация.
GFSе построен въз основа на следните критерии:

• Системата е изградена от голям брой обикновено евтино оборудване, което често се поврежда. Трябва да има наблюдение на повредите и възможност за възстановяване на функционирането на системата в случай на повреда на някое оборудване.
• Системата трябва да съхранява много големи файлове. Обикновено няколко милиона файла, всеки 100 MB или повече. Също така често е необходимо да се работи с многогигабайтови файлове, които също трябва да се съхраняват ефективно. Малки файлове също трябва да се съхраняват, но системата не е оптимизирана за тях.
• Обикновено има два типа четене: четене на голяма последователна част от данни и четене на малко количество произволни данни. При четене на голям поток от данни е обичайно да се изисква 1MB или по-голямо парче. Такива последователни операции от един клиент често четат последователни парчета от един и същи файл. Четенето не е голям размерданните, като правило, имат обем от няколко килобайта. Критичните във времето приложения трябва да натрупат определен брой такива заявки и да ги сортират по отместване от началото на файла. Това ще избегне изгледи напред-назад при четене.
• Често има операции за писане на голяма последователна част от данни, която трябва да се добави към файл. Обикновено количеството данни за запис е в същия ред, както и за четене. Малките записи, но на произволни места във файла, обикновено са неефективни.
• Системата трябва да реализира строго дефинирана семантика на паралелна работа на няколко клиента, ако едновременно се опитват да добавят данни към един и същ файл. В този случай може да се случи едновременно да се получат стотици заявки за запис в един файл. За да се справи с това, се използва атомарността на операциите по добавяне на данни към файла, с известна синхронизация. Тоест, ако се получи операция за четене, тя ще бъде изпълнена или преди следващата операция на запис, или след нея.
• Високата честотна лента се предпочита пред ниската латентност. Например повечето приложения в Google предпочитат да работят с тях големи обемиданни с висока скорост и изпълнението на една единствена операция за четене и запис, най-общо казано, може да бъде разтеглено.

Файловете в GFS са организирани йерархично с помощта на директории като всяка друга файлова система и се идентифицират по собствен път. Можете да извършвате обичайните операции с файлове в GFS: създаване, изтриване, отваряне, затваряне, четене и запис.
Освен това GFS поддържа резервни копия, или моментни снимки. Възможно е да се създават такива архиви за файлове или дървета на директории и то на ниска цена.

GFS архитектура

Чертежът е взет от оригиналната статия.

В системата има главни сървъри и чанк сървъри, които всъщност съхраняват данни. обикновено, GFSклъстерът се състои от един основна машина masters и много машини, съхраняващи чанк файлове chunkservers. Клиентите имат достъп до всички тези машини. Файловете в GFS са разделени на парчета (парчета, можете да кажете фрагмент). Чънк има фиксиран размеркоито могат да бъдат персонализирани. Всяка такава част има уникален и глобален 64-битов ключ, който се издава от капитана при създаването на парче. Чънк сървърите съхраняват парчета както обикновено Linux файлове, на вашия локален твърд диск. За надеждност всеки чанк може да бъде репликиран на други сървъри на парчета. Обикновено се използват три копия.
Капитанът отговаря за работата с метаданни за цялата файлова система. Метаданните включват пространства от имена, информация за контрол на достъпа до данни, съпоставяне на файлове в парчета и текущата позиция на блоковете. Капитанът също така контролира всички глобални системни дейности, като например управление на безплатни парчета, събиране на боклук (събиране на повече ненужни парчета) и преместване на парчета между сървъри на чанти. Майсторът непрекъснато обменя съобщения (HeartBeat съобщения) с chunk сървъри, за да даде инструкции и да определи тяхното състояние (разберете дали са все още живи).
Клиентът взаимодейства със съветника само за извършване на операции, свързани с метаданни. Всички операции със самите данни се извършват директно с chunk сървъри. GFS- системата не поддържа POSIX API, така че разработчиците не трябваше да се забъркват с VNode на ниво Linux.
Разработчиците не използват кеширане на данни, въпреки че клиентите кешират метаданни. На chunk сървъри операционната система Linux вече кешира най-използваните блокове в паметта. Като цяло, отхвърлянето на кеширането ви позволява да не мислите за проблема с валидността на кеша (съгласуваност на кеша).

майстор

Използването на един съветник значително опростява системната архитектура. Позволява ви да извършвате сложни движения на парчета, да организирате репликация с помощта на глобални данни. Изглежда, че наличието само на един главен трябва да бъде тесното място на системата, но това не е така. Клиентите никога не четат или записват данни чрез съветника. Вместо това те питат главния чанк сървър с кой сървър за чанк трябва да се свържат и след това комуникират директно със сървърите на чанк.
Нека видим как клиентът чете данни. Първо, знаейки размера на парчето,
името на файла и отместването спрямо началото на файла, клиентът определя номера на парчето вътре във файла. След това изпраща заявка до главната, съдържаща името на файла и номера на парчето в този файл. Главният издава чанк сървъри, по един във всяка реплика, които съхраняват чанка, от който се нуждаем. Главният също издава идентификатора на парчето на клиента.
След това клиентът решава коя от репликите му харесва повече (по правило тази, която е по-близка) и изпраща заявка, състояща се от парче и отместване спрямо началото на парчето. По-нататъшното четене на данни не изисква намесата на съветника. На практика, като правило, клиентът включва няколко парчета в една заявка за четене, а главният дава координатите на всяка от частите в един отговор.
Размерът на парчетата е важна характеристика на системата. Обикновено той е настроен на 64 мегабайта, което е много по-голямо от размера на блока в обикновена файлова система. Ясно е, че ако трябва да съхранявате много файлове, чиито размери по-малъкпарче, тогава ще похарчим много допълнителна памет... Но изборът на такъв голям размер на парчета се дължи на задачите, които Google трябва да решава на своите клъстери. По правило нещо трябва да се брои за всички документи в Интернет и следователно файловете в тези задачи са много големи.

Метаданни

Помощникът съхранява три важни типа метаданни: пространства от имена на файлове и парчета, съпоставяне между файл и част и позицията на репликите на парчета. Всички метаданни се съхраняват в паметта на капитана. Тъй като метаданните се съхраняват в паметта, съветникът работи бързо. Майсторът научава състоянието на нещата в системата просто и ефективно. Той сканира chunk сървъри във фонов режим. Тези периодични сканирания се използват за събиране на боклука, допълнителни репликации, в случай на откриване на недостъпен чанк сървър и преместване на чанкове, за балансиране на натоварването и свободното пространство на твърдите дискове на чанк сървърите.
Капитанът следи позицията на късовете. Когато чанк сървърът стартира, главният запомня неговите парчета. В процеса на работа капитанът контролира всички движения на чанкове и състоянието на чанк сървърите. По този начин той разполага с цялата информация за позицията на всяка част.
Важна част от метаданните е дневникът на дейността. Помощникът съхранява последователност от операции за нарушаване на промените в метаданните. Според тези знаци в дневника на операциите се определя логическото време на системата. Това е логичното време, което определя версиите на файловете и парчетата.
Тъй като дневникът на дейността е важна част, той трябва да се съхранява сигурно и всички промени в него трябва да стават видими за клиентите само когато се променят метаданните. Операционният дневник се реплицира на няколко отдалечени машини и системата отговаря на клиентската операция само след запазване на този дневник на главния диск и дисковете на отдалечените машини.
Помощникът възстановява състоянието на системата, като изпълнява дневник на операциите. Регистърът на операциите се поддържа сравнително малък, като се запазват само последните операции. В процеса на работа съветникът създава контролни точкикогато размерът на дневника надвиши определена стойност и системата може да бъде възстановена само до най-близката контролна точка. По-нататък по дневника можете да възпроизведете някои операции, така че системата да може да се върне обратно до точка, която е между последната контролна точка и текущо време.

Взаимодействия в системата

По-горе беше описана архитектурата на системата, която минимизира намесата на съветника при изпълнението на операциите. Сега нека да разгледаме как клиентът, главният и чанк сървърите взаимодействат, за да преместват данни, да извършват атомни записи и да създават резервно копие (моментна снимка).
Всяка промяна на парче трябва да бъде дублирана на всички реплики и да промени метаданните. V GFSгосподарят дава парче по време притежание(отдаване под наем) един от сървърите, съхраняващи този блок. Такъв сървър се нарича първична реплика. Останалите реплики са обявени за вторични. Първичната реплика събира последователни промени на парчета и всички реплики следват тази последователност, когато настъпят тези промени.
Механизъм притежания chunk е проектиран по такъв начин, че да минимизира натоварването на главния. Когато разпределя памет, първо изчаква 60 секунди. И тогава, ако е необходимо, основната реплика може да поиска от главния капитан да удължи този интервал и като правило получава положителен отговор. По време на този период на изчакване главният може да отмени промените.
Нека разгледаме по-отблизо процеса на запис на данни. Показано е стъпка по стъпка на фигурата, докато тънки линииконтролните потоци съответстват, а потоците от данни са с удебелен шрифт.


Тази цифра също е взета от оригиналната статия.

1. Клиентът пита капитана кой от сървърите на парчета притежава чанка и къде се намира този чанк в други реплики. Ако е необходимо, господарят дава парчето на някой, който притежава.
2. Главният отговаря с първичната реплика, а останалите (вторичните) реплики. Клиентът съхранява тези данни за по-нататъшни действия... Сега може да се наложи клиентът да комуникира с главната само ако основната реплика стане недостъпна.
3. След това клиентът изпраща данни до всички реплики. Той може да го направи в произволен ред. Всеки чанк сървър ще ги съхранява в специален буфер, докато не са необходими или не станат остарели.
4. Когато всички реплики приемат тези данни, клиентът изпраща заявка за запис към първичната реплика. Тази заявка съдържа самоличността на данните, изпратени в стъпка 3. Първичната реплика сега установява реда, в който всички промени, които получава, трябва да бъдат извършени, вероятно от множество клиенти паралелно. И след това извършва тези промени локално в този конкретен ред.
5. Първичната реплика препраща заявката за запис към всички вторични реплики. Всяка вторична реплика прави тези промени в реда, определен от първичната реплика.
6. Вторичните реплики съобщават за успеха на тези операции.
7. Първичната реплика изпраща отговор до клиента. Всички грешки, възникнали във всяка реплика, също се изпращат на клиента. Ако възникне грешка при записване към първичната реплика, тогава записът към вторичните реплики не се случва, в противен случай записът е възникнал в първичната реплика и подмножество от вторичните. В този случай клиентът обработва грешката и решава какво да прави с нея.

От примера по-горе можете да видите, че създателите са разделили потока от данни и контролния поток. Ако контролният поток отива само към първичната реплика, тогава потокът от данни отива към всички реплики. Това се прави, за да се избегне създаването на тесни места в мрежата и вместо това да се използва широко честотната лента на всяка машина. Също така, за да се избегнат тесни места и претоварени връзки, се използва схема за предаване до най-близкия съсед. мрежова топология... Да кажем, че клиентът предава данни към сървъри на парчета S1,..., S4... Клиентът изпраща данни до най-близкия сървър, нека S1... След това препраща към най-близкия сървър, нека бъде S2... По-нататък S2ги препраща към най-близкия S3или S4, и т.н.
Също така, латентността е сведена до минимум чрез използване на конвейер на предадените пакети данни TCP... Тоест, веднага щом чанк сървърът получи част от данните, той веднага започва да ги изпраща. Без претоварване на мрежата, идеално време за изпращане на обем данни Ббайт на Рреплики ще B / T + RL, където Tмрежова честотна лента и Л- латентност при прехвърлянето на един байт между две машини.
GFSподдържа операции като добавяне на атомни данни към файл. Обикновено, когато записваме някои данни във файл, ние посочваме тези данни и компенсираме. Ако няколко клиента произвеждат подобна операция, тогава тези операции не могат да бъдат пренаредени (това може да доведе до неправилна работа). Ако просто искаме да добавим данни към файла, тогава в този случай посочваме само самите данни. GFSще ги добави с атомна операция. Най-общо казано, ако една операция се провали на една от вторичните реплики, тогава GFS, ще върне грешка и данните ще бъдат различни в различните реплики.
Друг интересно нещо v GFS- това са резервни копия (можете да кажете и моментна снимка) на дървото на файл или директории, които се създават почти мигновено, като същевременно почти без прекъсване на текущите операции в системата. Това се постига чрез технология, подобна на копирайте при писане... Потребителите използват тази възможност за създаване на клонове на данни или като междинна точка, за да започнат някои експерименти.

Операции, извършвани от съветника

Капитанът е важно звено в системата. Той управлява репликацията на парчета: взема решения за поставяне, създава нови парчета и координира различни дейности в системата, за да поддържа парчетата напълно репликирани, да балансира натоварването на сървърите на парчета и да сглоби отново неизползваните ресурси.
За разлика от повечето файлови системи GFSне съхранява състава на файловете в директорията. GFSлогически представя пространството от имена като таблица, която съпоставя всеки път с метаданни. Такава таблица може ефективно да се съхранява в паметта като бор (речник на самите тези пътища). Всеки възел в това дърво (съответстващ или на абсолютен път към файл или към директория) има съответните данни за заключване за четене/запис. Всяка операция на съветника изисква установяване на някои ключалки. Това е мястото, където в системата се използват заключвания за четене/запис. Обикновено, ако операцията работи с /d1/d2/.../dn/лист, след което задава заключванията за четене на / d1, / d1 / d2, ..., d1 / d2 /.../ dnи блокиране, за четене или за писане d1 / d2 /.../ dn / лист... При което листможе да бъде или директория, или файл.
Нека покажем с пример как заключващият механизъм може да предотврати създаването на файл. / начало / потребител / fooпо време на архивиране / начало / потребител v / запиши / потребител... Операцията за архивиране задава заключванията за четене на / У домаи / спаси, както и блокиране за писане върху / начало / потребители / запиши / потребител... Операцията за създаване на файл изисква заключване за четене / У домаи / начало / потребител, както и блокиране за писане върху / начало / потребител / foo... По този начин втората операция няма да започне да се изпълнява, докато първата не приключи изпълнението, тъй като има конфликтно заключване / начало / потребител... При създаване на файл не се изисква заключване на запис на родителската директория, достатъчно е заключването за четене, за да се предотврати изтриването на тази директория.
Клъстери GFSса силно разпределени и наслоени. Обикновено такъв клъстер има стотици chunk сървъри, разположени на различни стелажи. Тези сървъри обикновено са достъпни за голям брой клиенти, разположени в една и съща или различна стойка. Връзките между две машини от различни стелажи могат да преминават през един или повече превключватели. Многостепенното разпределение е много трудна задачанадеждно, мащабируемо и достъпно разпространение на данни.
Политиката за оформление на репликата се опитва да удовлетвори следните свойства: максимизиране на надеждността и наличността на данните и максимално използване на мрежата. честотна лента... Репликите трябва да се намират не само на различни дисковеили различни коли, но още повече на различни стелажи. Това гарантира, че парчето е налично, дори ако целият багажник е повреден или изключен. При това подреждане четенето отнема време, приблизително равно на честотната лента на мрежата, но потокът от данни по време на запис трябва да преминава през различни стелажи.
Когато майсторът създаде парче, той избира къде да постави репликата. То идва от няколко фактора:

• Желателно е да се постави нова реплика на чанк сървър с най-ниско средно използване на диска. Това с течение на времето ще изравни натоварването на диска различни сървъри.
• Желателно е да се ограничи броят на новите създадени парчета на всеки чанк сървър. Въпреки факта, че създаването на парче само по себе си е бърза операция, то предполага последващо записване на данни в този блок, което вече е трудна операция и това може да доведе до дисбаланс в обема на трафика на данни към различни части на система.
• Както бе споменато по-горе, желателно е да се разпределят парчета между различни стелажи.

Веднага щом броят на репликите падне под определена от потребителя стойност, главният репликира парчето отново. Това може да се случи по няколко причини: сървърът на чанк е станал недостъпен, един от дисковете не работи или стойността, която определя броя на репликите, е увеличена. На всяка част, която трябва да бъде репликирана, се присвоява приоритет, който също зависи от няколко фактора. Първо, частта с най-малък брой реплики има по-висок приоритет. На второ място, за да се повиши надеждността на изпълнението на приложението, се увеличава приоритетът на чантите, които блокират напредъка на работата на клиента.
Главният избира чанта с най-висок приоритет и го копира, като инструктира един от сървърите на парчета да го копира от налична реплика. Новата реплика се намира по същите причини, както при създаването й.
По време на работата майсторът постоянно балансира репликите. В зависимост от разпределението на репликите в системата, той премества репликата, за да изравни използването на диска и да балансира натоварването. Също така, главният трябва да реши коя от репликите да бъде изтрита. По правило се премахва репликата, която се намира на сървъра за части с най-малко свободно място на твърдия диск.
Друг важна функциялежи на господаря е събиране на боклука. При изтриване на файл, GFSне изисква незабавно връщане на освободения дисково пространство... Той прави това по време на редовното събиране на боклука, което се случва както на ниво парче, така и на ниво файл. Авторите смятат, че този подход прави системата по-опростена и по-надеждна.
Когато даден файл бъде изтрит от приложение, съветникът запомня този факт в регистрационните файлове, както много други. Въпреки това, вместо да се изисква незабавно възстановяване на освободените ресурси, файлът просто се преименува, а времето за изтриване се добавя към името на файла и той става невидим за потребителя. И съветникът, по време на редовното сканиране на пространството от имена на файловата система, всъщност премахва всички такива скрити файлове, които са били изтрити от потребителя преди повече от три дни (този интервал е конфигурируем). До този момент файлът продължава да бъде в системата като скрит и може да бъде прочетен или преименуван обратно за възстановяване. Кога скрит файлсе изтрива от главния, след което информацията за него също се изтрива от метаданните и всички части от този файл се прекратяват връзката с него.
Помощникът, в допълнение към редовното сканиране на пространството от имена на файла, прави подобно сканиране на пространството от имена на парчета. Помощникът определя късовете, които се отделят от файла, премахва ги от метаданните и по време на редовни комуникации със сървърите на парчета им изпраща сигнал, че е възможно да се изтрият всички реплики, съдържащи дадена част. Този подход към събирането на боклука има много предимства, с един недостатък: ако на системата свърши място и мързеливото изтриване увеличава неизползваното пространство до самото физическо изхвърляне. Но има възможност за възстановяване на изтрити данни, възможност за гъвкаво балансиране на натоварването по време на изтриване и възможност за възстановяване на системата в случай на повреди.

Толерантност към грешки и диагностика на грешки

Авторите на системата смятат честите откази на компонентите на системата за един от най-трудните проблеми. Количеството и качеството на компонентите правят тези повреди не просто изключение, а по-скоро норма. Неизправността на компонента може да бъде причинена от липсата на този компонент или, по-лошо, повредени данни. GFSподдържа системата работеща с две прости стратегии: бързо възстановяванеи репликация.
Бързото възстановяване всъщност е рестартиране на машината. В същото време времето за стартиране е много кратко, което води до малка закачка и след това работата продължава нормално. Репликацията на парчета вече беше обсъдена по-горе. Главният репликира парче, ако една от репликите е станала недостъпна или данните, съдържащи репликата на частта, са повредени. Повредените парчета се определят чрез изчисляване на контролни суми.
Друг вид репликация в системата, за която малко се говори, е главната репликация. Операционният дневник и контролните точки се репликират. Всяка промяна на файловете в системата се случва само след като съветникът запише дневника на операциите на дисковете и дисковете на машините, на които се репликира дневникът. В случай на незначителни проблеми съветникът може да се рестартира. В случай на проблеми с твърд дискили друга жизненоважна главна инфраструктура, GFS стартира нов главен файл на една от машините, където са репликирани данните на главния. Клиентите се позовават на DNS съветник, който може да бъде преназначен на нова машина. Новият майстор е сянка на стария, а не точно копие. Следователно той има достъп само за четене до файловете. Тоест, той не става пълноправен господар, а само поддържа дневник на операциите и други структури на капитана.
Важна част от системата е способността да се поддържа целостта на данните. Нормално GFSклъстерът се състои от стотици машини, на които има хиляди твърди дискове, а тези дискове, когато работят със завидна постоянство, се провалят, което води до повреда на данните. Системата може да възстанови данни с помощта на репликация, но за това е необходимо да се разбере дали данните са се влошили. Простото сравняване на различни реплики на различни чанк сървъри е неефективно. Освен това може да възникне несъответствие на данните между различните реплики, което да доведе до разлики в данните. Следователно всеки сървър на парчета трябва самостоятелно да определи целостта на данните.
Всяко парче е разделено на блокове с дължина 64 kB... Всеки такъв блок съответства на 32 -битова контролна сума. Подобно на други метаданни, тези количества се съхраняват в паметта, редовно се записват в дневника, отделно от потребителските данни.
Преди да прочете данните, сървърът на парчета проверява контролни сумиблокове на блокове, които се пресичат с исканите данни от потребителя или друг сървър на блокове. Това означава, че чанк сървърът не разпространява повредени данни. Ако контролните суми не съвпадат, сървърът на парчета връща грешката на машината, която е изпратила заявката, и я докладва на главния. Потребителят може да чете данни от друга реплика, а главният създава друго копие от данните от другата реплика. След това главният инструктира този чанк сървър да премахне тази повредена реплика.
При добавяне на нови данни контролните суми не се проверяват, а за блоковете се записват нови контролни суми. Ако дискът е повреден, той ще бъде открит при опит за четене на тези данни. Когато записва, chunk сървърът сравнява само първия и последния блок, които се пресичат с границите, в които се извършва записването, тъй като някои от данните в тези блокове не се презаписват и е необходимо да се провери тяхната цялост.

Pr0grammer 29 октомври 2009 г. в 01:31 ч

Разпределена файлова система GFS (файлова система на Google)

• Изработка на уебсайтове

В момента, в контекста на нарастването на информацията, има проблеми със съхраняването и обработката на много големи данни. Следователно тези данни се обработват на няколко сървъра едновременно, които образуват клъстери. За да се опрости работата с данни в клъстери, се разработват разпределени файлови системи. Ще разгледаме по-отблизо пример за разпределена файлова система. Google файлова системаизползвани от компанията Google... (Статията всъщност е свободен и съкратен превод на оригиналната статия).

GFSе може би най-известната разпределена файлова система. Надеждното, мащабируемо съхранение на данни е от съществено значение за всяко приложение, работещо с толкова голямо количество данни като всички документи в Интернет. GFSе основната платформа за съхранение на информация в Google. GFSе голяма разпределена файлова система, способна да съхранява и обработва огромни количества информация.
GFSе построен въз основа на следните критерии:

• Системата е изградена от голям брой обикновено евтино оборудване, което често се поврежда. Трябва да има наблюдение на повредите и възможност за възстановяване на функционирането на системата в случай на повреда на някое оборудване.
• Системата трябва да съхранява много големи файлове. Обикновено няколко милиона файла, всеки 100 MB или повече. Също така често е необходимо да се работи с многогигабайтови файлове, които също трябва да се съхраняват ефективно. Малки файлове също трябва да се съхраняват, но системата не е оптимизирана за тях.
• Обикновено има два типа четене: четене на голяма последователна част от данни и четене на малко количество произволни данни. При четене на голям поток от данни е обичайно да се изисква 1MB или по-голямо парче. Такива последователни операции от един клиент често четат последователни парчета от един и същи файл. Четенето на малък размер на данни, като правило, има обем от няколко килобайта. Критичните във времето приложения трябва да натрупат определен брой такива заявки и да ги сортират по отместване от началото на файла. Това ще избегне изгледи напред-назад при четене.
• Често има операции за писане на голяма последователна част от данни, която трябва да се добави към файл. Обикновено количеството данни за запис е в същия ред, както и за четене. Малките записи, но на произволни места във файла, обикновено са неефективни.
• Системата трябва да реализира строго дефинирана семантика на паралелна работа на няколко клиента, ако едновременно се опитват да добавят данни към един и същ файл. В този случай може да се случи едновременно да се получат стотици заявки за запис в един файл. За да се справи с това, се използва атомарността на операциите по добавяне на данни към файла, с известна синхронизация. Тоест, ако се получи операция за четене, тя ще бъде изпълнена или преди следващата операция на запис, или след нея.
• Високата честотна лента се предпочита пред ниската латентност. Така че повечето приложения в Google предпочитат да работят с големи количества данни, с висока скорост и изпълнението на една единствена операция за четене и запис, най-общо казано, може да бъде разтеглено.

Файловете в GFS са организирани йерархично с помощта на директории като всяка друга файлова система и се идентифицират по собствен път. Можете да извършвате обичайните операции с файлове в GFS: създаване, изтриване, отваряне, затваряне, четене и запис.
Освен това GFS поддържа архивиране или моментни снимки. Възможно е да се създават такива архиви за файлове или дървета на директории и то на ниска цена.

GFS архитектура

Чертежът е взет от оригиналната статия.

В системата има главни сървъри и чанк сървъри, които всъщност съхраняват данни. обикновено, GFSклъстерът се състои от една главна машина (master) и много машини, съхраняващи фрагменти от файлове chunk-servers (chunkservers). Клиентите имат достъп до всички тези машини. Файловете в GFS са разделени на парчета (парчета, можете да кажете фрагмент). Парчето има фиксиран размер, който може да бъде персонализиран. Всяка такава част има уникален и глобален 64-битов ключ, който се издава от капитана при създаването на парче. Chunk сървърите съхраняват парчета като обикновени Linux файлове на локален твърд диск. За надеждност всеки чанк може да бъде репликиран на други сървъри на парчета. Обикновено се използват три копия.
Капитанът отговаря за работата с метаданни за цялата файлова система. Метаданните включват пространства от имена, информация за контрол на достъпа до данни, съпоставяне на файлове в парчета и текущата позиция на блоковете. Капитанът също така контролира всички глобални системни дейности, като например управление на безплатни парчета, събиране на боклук (събиране на повече ненужни парчета) и преместване на парчета между сървъри на чанти. Майсторът непрекъснато обменя съобщения (HeartBeat съобщения) с chunk сървъри, за да даде инструкции и да определи тяхното състояние (разберете дали са все още живи).
Клиентът взаимодейства със съветника само за извършване на операции, свързани с метаданни. Всички операции със самите данни се извършват директно с chunk сървъри. GFS- системата не поддържа POSIX API, така че разработчиците не трябваше да се забъркват с VNode на ниво Linux.
Разработчиците не използват кеширане на данни, въпреки че клиентите кешират метаданни. На chunk сървъри операционната система Linux вече кешира най-използваните блокове в паметта. Като цяло, отхвърлянето на кеширането ви позволява да не мислите за проблема с валидността на кеша (съгласуваност на кеша).

майстор

Използването на един съветник значително опростява системната архитектура. Позволява ви да извършвате сложни движения на парчета, да организирате репликация с помощта на глобални данни. Изглежда, че наличието само на един главен трябва да бъде тесното място на системата, но това не е така. Клиентите никога не четат или записват данни чрез съветника. Вместо това те питат главния чанк сървър с кой сървър за чанк трябва да се свържат и след това комуникират директно със сървърите на чанк.
Нека видим как клиентът чете данни. Първо, знаейки размера на парчето,
името на файла и отместването спрямо началото на файла, клиентът определя номера на парчето вътре във файла. След това изпраща заявка до главната, съдържаща името на файла и номера на парчето в този файл. Главният издава чанк сървъри, по един във всяка реплика, които съхраняват чанка, от който се нуждаем. Главният също издава идентификатора на парчето на клиента.
След това клиентът решава коя от репликите му харесва повече (по правило тази, която е по-близка) и изпраща заявка, състояща се от парче и отместване спрямо началото на парчето. По-нататъшното четене на данни не изисква намесата на съветника. На практика, като правило, клиентът включва няколко парчета в една заявка за четене, а главният дава координатите на всяка от частите в един отговор.
Размерът на парчетата е важна характеристика на системата. Обикновено той е настроен на 64 мегабайта, което е много по-голямо от размера на блока в обикновена файлова система. Ясно е, че ако е необходимо да се съхраняват много файлове, чиито размери са по-малки от размера на парчето, тогава ще консумираме много допълнителна памет. Но изборът на такъв голям размер на парчета се дължи на задачите, които Google трябва да решава на своите клъстери. По правило нещо трябва да се брои за всички документи в Интернет и следователно файловете в тези задачи са много големи.

Метаданни

Помощникът съхранява три важни типа метаданни: пространства от имена на файлове и парчета, съпоставяне между файл и част и позицията на репликите на парчета. Всички метаданни се съхраняват в паметта на капитана. Тъй като метаданните се съхраняват в паметта, съветникът работи бързо. Майсторът научава състоянието на нещата в системата просто и ефективно. Той сканира chunk сървъри във фонов режим. Тези периодични сканирания се използват за събиране на боклука, допълнителни репликации, в случай на откриване на недостъпен чанк сървър и преместване на чанкове, за балансиране на натоварването и свободното пространство на твърдите дискове на чанк сървърите.
Капитанът следи позицията на късовете. Когато чанк сървърът стартира, главният запомня неговите парчета. В процеса на работа капитанът контролира всички движения на чанкове и състоянието на чанк сървърите. По този начин той разполага с цялата информация за позицията на всяка част.
Важна част от метаданните е дневникът на дейността. Помощникът съхранява последователност от операции за нарушаване на промените в метаданните. Според тези знаци в дневника на операциите се определя логическото време на системата. Това е логичното време, което определя версиите на файловете и парчетата.
Тъй като дневникът на дейността е важна част, той трябва да се съхранява сигурно и всички промени в него трябва да стават видими за клиентите само когато се променят метаданните. Операционният дневник се реплицира на няколко отдалечени машини и системата отговаря на клиентската операция само след запазване на този дневник на главния диск и дисковете на отдалечените машини.
Помощникът възстановява състоянието на системата, като изпълнява дневник на операциите. Регистърът на операциите се поддържа сравнително малък, като се запазват само последните операции. В процеса съветникът създава контролни точки, когато размерът на дневника надвиши определена стойност и системата може да бъде възстановена само до най-близката контролна точка. По-нататък по дневника можете да възпроизведете някои операции, като по този начин системата може да се върне обратно до точка, която е между последната контролна точка и текущото време.

Взаимодействия в системата

По-горе беше описана архитектурата на системата, която минимизира намесата на съветника при изпълнението на операциите. Сега нека да разгледаме как клиентът, главният и чанк сървърите взаимодействат, за да преместват данни, да извършват атомни записи и да създават резервно копие (моментна снимка).
Всяка промяна на парче трябва да бъде дублирана на всички реплики и да промени метаданните. V GFSгосподарят дава парче по време притежание(отдаване под наем) един от сървърите, съхраняващи този блок. Такъв сървър се нарича първична реплика. Останалите реплики са обявени за вторични. Първичната реплика събира последователни промени на парчета и всички реплики следват тази последователност, когато настъпят тези промени.
Механизъм притежания chunk е проектиран по такъв начин, че да минимизира натоварването на главния. Когато разпределя памет, първо изчаква 60 секунди. И тогава, ако е необходимо, основната реплика може да поиска от главния капитан да удължи този интервал и като правило получава положителен отговор. По време на този период на изчакване главният може да отмени промените.
Нека разгледаме по-отблизо процеса на запис на данни. Той е показан на стъпки на фигурата, с тънки линии, представляващи контролни потоци, и удебели линии, представляващи потоци от данни.


Тази цифра също е взета от оригиналната статия.

1. Клиентът пита капитана кой от сървърите на парчета притежава чанка и къде се намира този чанк в други реплики. Ако е необходимо, господарят дава парчето на някой, който притежава.
2. Главният отговаря с първичната реплика, а останалите (вторичните) реплики. Клиентът съхранява тези данни за по-нататъшни действия. Сега може да се наложи клиентът да комуникира с главната само ако основната реплика стане недостъпна.
3. След това клиентът изпраща данни до всички реплики. Той може да го направи в произволен ред. Всеки чанк сървър ще ги съхранява в специален буфер, докато не са необходими или не станат остарели.
4. Когато всички реплики приемат тези данни, клиентът изпраща заявка за запис към първичната реплика. Тази заявка съдържа самоличността на данните, изпратени в стъпка 3. Първичната реплика сега установява реда, в който всички промени, които получава, трябва да бъдат извършени, вероятно от множество клиенти паралелно. И след това извършва тези промени локално в този конкретен ред.
5. Първичната реплика препраща заявката за запис към всички вторични реплики. Всяка вторична реплика прави тези промени в реда, определен от първичната реплика.
6. Вторичните реплики съобщават за успеха на тези операции.
7. Първичната реплика изпраща отговор до клиента. Всички грешки, възникнали във всяка реплика, също се изпращат на клиента. Ако възникне грешка при записване към първичната реплика, тогава записът към вторичните реплики не се случва, в противен случай записът е възникнал в първичната реплика и подмножество от вторичните. В този случай клиентът обработва грешката и решава какво да прави с нея.

От примера по-горе можете да видите, че създателите са разделили потока от данни и контролния поток. Ако контролният поток отива само към първичната реплика, тогава потокът от данни отива към всички реплики. Това се прави, за да се избегне създаването на тесни места в мрежата и вместо това да се използва широко честотната лента на всяка машина. Също така, за да се избегнат тесни места и претоварени връзки, се използва схема за предаване до най-близкия съсед в топологията на мрежата. Да кажем, че клиентът предава данни към сървъри на парчета S1,..., S4... Клиентът изпраща данни до най-близкия сървър, нека S1... След това препраща към най-близкия сървър, нека бъде S2... По-нататък S2ги препраща към най-близкия S3или S4, и т.н.
Също така, латентността е сведена до минимум чрез използване на конвейер на предадените пакети данни TCP... Тоест, веднага щом чанк сървърът получи част от данните, той веднага започва да ги изпраща. Без претоварване на мрежата, идеално време за изпращане на обем данни Ббайт на Рреплики ще B / T + RL, където Tмрежова честотна лента и Л- латентност при прехвърлянето на един байт между две машини.
GFSподдържа операции като добавяне на атомни данни към файл. Обикновено, когато записваме някои данни във файл, ние посочваме тези данни и компенсираме. Ако няколко клиента извършват подобна операция, тогава тези операции не могат да бъдат пренаредени (това може да доведе до неправилна операция). Ако просто искаме да добавим данни към файла, тогава в този случай посочваме само самите данни. GFSще ги добави с атомна операция. Най-общо казано, ако една операция се провали на една от вторичните реплики, тогава GFS, ще върне грешка и данните ще бъдат различни в различните реплики.
Още едно страхотно нещо за GFS- това са резервни копия (можете да кажете и моментна снимка) на дървото на файл или директории, които се създават почти мигновено, като същевременно почти без прекъсване на текущите операции в системата. Това се постига чрез технология, подобна на копирайте при писане... Потребителите използват тази възможност за създаване на клонове на данни или като междинна точка, за да започнат някои експерименти.

Операции, извършвани от съветника

Капитанът е важно звено в системата. Той управлява репликацията на парчета: взема решения за поставяне, създава нови парчета и координира различни дейности в системата, за да поддържа парчетата напълно репликирани, да балансира натоварването на сървърите на парчета и да сглоби отново неизползваните ресурси.
За разлика от повечето файлови системи GFSне съхранява състава на файловете в директорията. GFSлогически представя пространството от имена като таблица, която съпоставя всеки път с метаданни. Такава таблица може ефективно да се съхранява в паметта като бор (речник на самите тези пътища). Всеки възел в това дърво (съответстващ или на абсолютен път към файл или към директория) има съответните данни за заключване за четене/запис. Всяка операция на съветника изисква установяване на някои ключалки. Това е мястото, където в системата се използват заключвания за четене/запис. Обикновено, ако операцията работи с /d1/d2/.../dn/лист, след което задава заключванията за четене на / d1, / d1 / d2, ..., d1 / d2 /.../ dnи блокиране, за четене или за писане d1 / d2 /.../ dn / лист... При което листможе да бъде или директория, или файл.
Нека покажем с пример как заключващият механизъм може да предотврати създаването на файл. / начало / потребител / fooпо време на архивиране / начало / потребител v / запиши / потребител... Операцията за архивиране задава заключванията за четене на / У домаи / спаси, както и блокиране за писане върху / начало / потребители / запиши / потребител... Операцията за създаване на файл изисква заключване за четене / У домаи / начало / потребител, както и блокиране за писане върху / начало / потребител / foo... По този начин втората операция няма да започне да се изпълнява, докато първата не приключи изпълнението, тъй като има конфликтно заключване / начало / потребител... При създаване на файл не се изисква заключване на запис на родителската директория, достатъчно е заключването за четене, за да се предотврати изтриването на тази директория.
Клъстери GFSса силно разпределени и наслоени. Обикновено такъв клъстер има стотици chunk сървъри, разположени на различни стелажи. Тези сървъри обикновено са достъпни за голям брой клиенти, разположени в една и съща или различна стойка. Връзките между две машини от различни стелажи могат да преминават през един или повече превключватели. Разпределението на нива е много трудна задача за надеждно, мащабируемо и достъпно разпределение на данни.
Политиката за оформление на репликата се опитва да удовлетвори следните свойства: максимизиране на надеждността и наличността на данните и максимално използване на мрежовата честотна лента. Репликите трябва да бъдат разположени не само на различни дискове или различни машини, но и на различни стелажи. Това гарантира, че парчето е налично, дори ако целият багажник е повреден или изключен. При това подреждане четенето отнема време, приблизително равно на честотната лента на мрежата, но потокът от данни по време на запис трябва да преминава през различни стелажи.
Когато майсторът създаде парче, той избира къде да постави репликата. То идва от няколко фактора:

• Желателно е да се постави нова реплика на чанк сървър с най-ниско средно използване на диска. Това с течение на времето ще изравни използването на диска на различни сървъри.
• Желателно е да се ограничи броят на новите създадени парчета на всеки чанк сървър. Въпреки факта, че създаването на парче само по себе си е бърза операция, то предполага последващо записване на данни в този блок, което вече е трудна операция и това може да доведе до дисбаланс в обема на трафика на данни към различни части на система.
• Както бе споменато по-горе, желателно е да се разпределят парчета между различни стелажи.

Веднага щом броят на репликите падне под определена от потребителя стойност, главният репликира парчето отново. Това може да се случи по няколко причини: сървърът на чанк е станал недостъпен, един от дисковете не работи или стойността, която определя броя на репликите, е увеличена. На всяка част, която трябва да бъде репликирана, се присвоява приоритет, който също зависи от няколко фактора. Първо, частта с най-малък брой реплики има по-висок приоритет. На второ място, за да се повиши надеждността на изпълнението на приложението, се увеличава приоритетът на чантите, които блокират напредъка на работата на клиента.
Главният избира чанта с най-висок приоритет и го копира, като инструктира един от сървърите на парчета да го копира от налична реплика. Новата реплика се намира по същите причини, както при създаването й.
По време на работата майсторът постоянно балансира репликите. В зависимост от разпределението на репликите в системата, той премества репликата, за да изравни използването на диска и да балансира натоварването. Също така, главният трябва да реши коя от репликите да бъде изтрита. По правило се премахва репликата, която се намира на сървъра за части с най-малко свободно място на твърдия диск.
Друга важна функция на капитана е събирането на боклука. При изтриване на файл, GFSне изисква незабавно връщане на освободеното дисково пространство. Той прави това по време на редовното събиране на боклука, което се случва както на ниво парче, така и на ниво файл. Авторите смятат, че този подход прави системата по-опростена и по-надеждна.
Когато даден файл бъде изтрит от приложение, съветникът запомня този факт в регистрационните файлове, както много други. Въпреки това, вместо да се изисква незабавно възстановяване на освободените ресурси, файлът просто се преименува, а времето за изтриване се добавя към името на файла и той става невидим за потребителя. И съветникът, по време на редовното сканиране на пространството от имена на файловата система, всъщност премахва всички такива скрити файлове, които са били изтрити от потребителя преди повече от три дни (този интервал е конфигурируем). До този момент файлът продължава да бъде в системата като скрит и може да бъде прочетен или преименуван обратно за възстановяване. Когато скрит файл бъде изтрит от главния, информацията за него също се премахва от метаданните и всички части от този файл се отделят от него.
Помощникът, в допълнение към редовното сканиране на пространството от имена на файла, прави подобно сканиране на пространството от имена на парчета. Помощникът определя късовете, които се отделят от файла, премахва ги от метаданните и по време на редовни комуникации със сървърите на парчета им изпраща сигнал, че е възможно да се изтрият всички реплики, съдържащи дадена част. Този подход към събирането на боклука има много предимства, с един недостатък: ако на системата свърши място и мързеливото изтриване увеличава неизползваното пространство до самото физическо изхвърляне. Но има възможност за възстановяване на изтрити данни, възможност за гъвкаво балансиране на натоварването по време на изтриване и възможност за възстановяване на системата в случай на повреди.

Толерантност към грешки и диагностика на грешки

Авторите на системата смятат честите откази на компонентите на системата за един от най-трудните проблеми. Количеството и качеството на компонентите правят тези повреди не просто изключение, а по-скоро норма. Неизправността на компонента може да бъде причинена от липсата на този компонент или, по-лошо, повредени данни. GFSподдържа системата работеща с две прости стратегии: бързо възстановяване и репликация.
Бързото възстановяване всъщност е рестартиране на машината. В същото време времето за стартиране е много кратко, което води до малка закачка и след това работата продължава нормално. Репликацията на парчета вече беше обсъдена по-горе. Главният репликира парче, ако една от репликите е станала недостъпна или данните, съдържащи репликата на частта, са повредени. Повредените парчета се определят чрез изчисляване на контролни суми.
Друг вид репликация в системата, за която малко се говори, е главната репликация. Операционният дневник и контролните точки се репликират. Всяка промяна на файловете в системата се случва само след като съветникът запише дневника на операциите на дисковете и дисковете на машините, на които се репликира дневникът. В случай на незначителни проблеми съветникът може да се рестартира. В случай на проблеми с твърдия диск или друга жизненоважна инфраструктура на главната, GFS стартира нов главен, на една от машините, където са репликирани данните на главната. Клиентите се позовават на DNS съветник, който може да бъде преназначен на нова машина. Новият майстор е сянка на стария, а не точно копие. Следователно той има достъп само за четене до файловете. Тоест, той не става пълноправен господар, а само поддържа дневник на операциите и други структури на капитана.
Важна част от системата е способността да се поддържа целостта на данните. Нормално GFSедин клъстер се състои от стотици машини, съдържащи хиляди твърди дискове, и тези дискове, когато работят със завидна постоянство, се отказват, което води до повреда на данните. Системата може да възстанови данни с помощта на репликация, но за това е необходимо да се разбере дали данните са се влошили. Простото сравняване на различни реплики на различни чанк сървъри е неефективно. Освен това може да възникне несъответствие на данните между различните реплики, което да доведе до разлики в данните. Следователно всеки сървър на парчета трябва самостоятелно да определи целостта на данните.
Всяко парче е разделено на блокове с дължина 64 kB... Всеки такъв блок съответства на 32 -битова контролна сума. Подобно на други метаданни, тези количества се съхраняват в паметта, редовно се записват в дневника, отделно от потребителските данни.
Преди да прочете данните, чанк сървърът проверява контролните суми на блоковете на блоковете, които се пресичат с исканите данни от потребителя или друг сървър на парчета. Това означава, че чанк сървърът не разпространява повредени данни. Ако контролните суми не съвпадат, сървърът на парчета връща грешката на машината, която е изпратила заявката, и я докладва на главния. Потребителят може да чете данни от друга реплика, а главният създава друго копие от данните от другата реплика. След това главният инструктира този чанк сървър да премахне тази повредена реплика.
При добавяне на нови данни контролните суми не се проверяват, а за блоковете се записват нови контролни суми. Ако дискът е повреден, той ще бъде открит при опит за четене на тези данни. Когато записва, chunk сървърът сравнява само първия и последния блок, които се пресичат с границите, в които се извършва записването, тъй като някои от данните в тези блокове не се презаписват и е необходимо да се провери тяхната цялост. Две основни цели.

Мрежова прозрачност.
Най-важната цел е да се осигурят същите възможности за достъп до файлове, разпределени в компютърна мрежа, които се предоставят в системите за споделяне на време на централизирани компютри.

Висока наличност.
Друга важна цел е да се гарантира висока наличност... Системни грешки или операции по копиране и поддръжка не трябва да правят файловете недостъпни.

Концепция за файлова услуга и файлов сървър.

Файлова услугае това, което файловата система предоставя на своите клиенти, т.е. интерфейс на файловата система.
Файлов сървъре процес, който прилага файлова услуга.

Потребителят не трябва да знае колко файлови сървъри има или къде се намират.

Тъй като файлов сървър обикновено е нормален потребителски процес, системата може да има различни файлови сървъри, които предоставят различни услуги (напр. UNIX файлобслужване и MS-DOS файлобслужване).

5.1 Архитектура на разпределена файлова система

Разпределената система обикновено има два значително различни компонента – самата файлова услуга и услугата на директории.

5.1.1 Интерфейс на файловия сървър

За всяка файлова система първият основен въпрос е какво е файл. На много системи, като UNIX и MS-DOS, файлът не е такъв интерпретирана последователност от байтове. На многоцентрализирани компютри (IBM / 370) файлът е представен от поредица от записи, които могат да бъдат посочени чрез неговия номер или съдържанието на някакво поле (ключ). Тъй като повечето разпределени системи са базирани на UNIX и MS-DOS средата, те използват първата версия на файловата концепция.

Файлът може да има атрибути(информация за файл, който не е част от него). Типичните атрибути са собственик, размер, дата на създаване и права за достъп.

Важен аспект на файловия модел е дали файловете могат модифицирайтеслед създаването. Обикновено могат, но има системи с неизменни файлове. Такива файлове освобождават разработчиците от много проблеми с кеширането и разпространението.

Защитаосигурени от същите механизми като при еднопроцесорните компютри – мандати и списъци с права за достъп. Мандатът е вид билет, издаден на потребителя за всеки файл с индикация за права за достъп. Списъкът с права за достъп определя за всеки файл списък с потребители с техните права. Най-простата схема с права за достъп е UNIX схемата, в която има три типа достъп (четене, запис, изпълнение) и три типа потребители (собственик, членове на неговата група и други).

Файловата услуга може да се базира на един от двата модела - модела товарене/разтоварванеи модели отдалечен достъп ... В първия случай файлът се прехвърля между клиента (памет или дискове) и сървъра като цяло, а във втория файловата услуга осигурява много операции (отваряне, затваряне, четене и запис на част от файла, изместване на указател, проверка и промяна на атрибути и др.). Първият подход изисква голямо количество памет на клиента, разходите за преместване на ненужни части от файла. При втория подход файловата система функционира на сървъра, клиентът може да няма дискове и много памет.

5.1.2 Интерфейс на сървъра на директории

Осигурява операции за създаване и изтриване на директории, именуване и преименуване на файлове, преместване на файлове от една директория в друга.

Дефинира азбуката и синтаксиса за имената. За спецификация Тип информация във файла, се използва или част от името (разширение) или изричен атрибут.

Всички разпределени системи позволяват на директории да съдържат поддиректории - тази файлова система се нарича йерархичен ... Някои системи ви позволяват да създавате указатели или връзки към произволни директории, които могат да бъдат поставени в директория. В този случай можете да изграждате не само дървета, но и произволни графики (разликата между тях е много важна за разпределените системи, тъй като в случай на графика изтриването на връзка може да доведе до появата на недостижими поддървета. Много е трудни за откриване на такива поддървета в разпределени системи).

Ключово решение при проектирането на разпределена файлова система е дали машините (или процесите) трябва или не трябва да виждат йерархията на директориите по същия начин. Тясно свързано с това решение е наличието на единична основна директория (можете да имате такава директория с поддиректории за всеки сървър).

Прозрачност на именуването.
Две форми на прозрачност на именуването разграничават прозрачността на местоположението (/ server / d1 / f1) и прозрачността на миграцията (при която промяната на местоположението на файл не изисква промяна на името).

Има три подхода за именуване:


• кола + пътека;
• монтиране на отдалечени файлови системи в локалната файлова йерархия;
• единственото пространство от имена, което изглежда еднакво на всички машини.

Последният подход е необходим за постигане на разпределена система, която изглежда като един компютър, но е сложен и изисква внимателно проектиране.

Именуване на две нива.
Повечето системи използват някаква форма на именуване на две нива. Файловете (и други обекти) имат символни имена за потребителите, но могат да имат и вътрешни двоични имена за използване от самата система. Например при операцията за отваряне на файл потребителят посочва символно име и в замяна получава двоично име, което използва при всички други операции с този файл. Начинът, по който се формират двоичните имена, се различава от система до система:

• ако има няколко сървъра, които не се отнасят един към друг (директориите не съдържат препратки към обекти на други сървъри), тогава двоичното име може да бъде същото като в UNIX OS;
• името може да сочи към сървър и файл;
• Като двоични имена при търсене на символни имена се връщат идентификационни данни, които съдържат, в допълнение към правата за достъп, или физическия номер на машината със сървъра, или мрежовия адрес на сървъра и номера на файла.

В отговор на символното име някои системи могат да върнат множество двоични имена (за файла и неговите дубликати), което подобрява надеждността на файла.

5.1.3 Семантика на разделяне на файлове

UNIX семантика
Естествената семантика на еднопроцесорния компютър е, че ако операцията на запис е последвана от четене, тогава резултатът се определя от последната от предходните операции на запис. V разпределена систематази семантика е лесна за постигане само когато има един файлов сървър и клиентите нямат кеш. Семантиката се нарушава при наличието на кешове. Необходимо е или незабавно да се отразят всички промени в кеша във файловете, или да се промени семантиката на разделяне на файлове.

Неизменни файлове - много радикален подход за промяна на семантиката на разделяне на файлове.
Има само две операции - създаване и четене. Можете да замените стария файл с новия файл - т.е. можете да сменяте директории. Ако един процес чете файл, а друг го замества, тогава можете да оставите първия процес да модифицира стария файл, докато други процеси може вече да работят с новия. Семантика на сесията Промените в отворен файл са видими само за процеса (или машината), който прави тези промени, и само след като файлът бъде затворен, те стават видими за други процеси (или машини). Какво се случва, ако два процеса работят едновременно върху един и същ файл - или резултатът ще бъде определен от процеса, който последно е затворил файла, или може само да се твърди, че една от двете версии на файла ще стане текущата.

Транзакции
Процесът издава операция НАЧАЛНА ТРАНЗАКЦИЯ, което показва, че следващите операции трябва да се извършват без намесата на други процеси. След това издава последователност от четене и запис, завършваща с операция END TRANSACTION. Ако няколко транзакции стартират едновременно, системата гарантира, че резултатът ще бъде същият, какъвто би бил при последователно изпълнение на транзакции (в неопределен ред). Пример е банкирането.

5.2 Внедряване на разпределени файлови системи

Обсъдените по-горе аспекти на разпределените файлови системи, които са видими за потребителя. Аспектите на прилагане са обсъдени по-долу.

5.2.1 Използване на файлове

Много е важно да разберете как ще се използва системата, когато започнете да внедрявате. Ето резултатите от някои изследвания относно използването на файлове (статични и динамични) в университетите. Много е важно да се оцени представителността на изследваните данни.

• повечето файлове са по-малки от 10K (трябва да бъдат изтеглени изцяло).
• четенето е много по-често срещано от писането (кеширане).
• четенията и записите са последователни, произволният достъп е рядък (кеш напред, четене при четене, изскачане след запис трябва да бъдат групирани).
• повечето файлове имат кратък живот (създайте файл в клиента и го съхранявайте там, докато не бъде унищожен).
• споделени са няколко файла (клиентско кеширане и семантика на сесията).
• има различни класове файлове с различни свойства (трябва да имате различни механизми в системата за различните класове).

5.2.2 Структура на системата

Независимо дали има a разлика между клиенти и сървъри? Има системи, при които всички машини имат един и същ софтуер и всяка машина може да предостави файлова услуга. Има системи, в които сървърите са обикновени потребителски процеси и могат да бъдат конфигурирани да работят на една и съща машина с клиенти или на различни. Има системи, в които клиентите и сървърите са фундаментално различни машини по отношение на хардуера или софтуера (изисква се различни операционни системи, например).

Втори въпрос- дали файловият сървър и сървърът на директории трябва да бъдат отделни сървъри или да бъдат комбинирани в един сървър. Разделянето на дялове ви позволява да имате различни сървъри на директории (UNIX, MS-DOS) и един файлов сървър. Консолидацията намалява разходите за комуникация.

Ако сървърите са разделени и има различни сървъри на директории за различни поддървета, възниква следният проблем. Ако първият извикан сървър има достъп до всички следващи на свой ред, има големи комуникационни разходи. Ако първият сървър предаде останалата част от името на втория, а това на третия и т.н., тогава това не позволява използването на RPC.

Възможно решение е да използвате кеша за подсказки. Въпреки това, в този случай, когато получава наследените директории с двоични имена от сървъра, клиентът трябва да бъде подготвен да се провали от файловия сървър и да получи повторен достъп до сървъра на директории (клиентът може да не е краен потребител!).

Последният важен въпрос- дали сървърите трябва да съхраняват информация за клиенти.

Сървъри със състояние. достойнство.

• По-кратки съобщения (двоичните имена използват отворена файлова таблица).
• по-висока ефективност (информация за отворени файловеможе да се съхранява в RAM).
• блокове информация могат да бъдат прочетени предварително.
• по-лесно е да се провери валидността на заявка, ако има състояние (например съхраняване на номера на последната заявка).
• е възможна операция за улавяне на файл.

Сървъри без състояние ... достойнство.

• устойчивост на грешки.
• не се изискват операции ОТВАРЯНЕ/ЗАТВАРЯНЕ.
• не се изисква памет за таблици.
• няма ограничение за броя на отворените файлове.
• няма проблем със срив на клиент.

5.2.3 Кеширане

В клиент/сървър система с памет и дискове има четири потенциални места за съхранение на файлове или части от тях.

Първо, съхранението на файлове на сървърни дискове. Няма проблем с кохерентността, тъй като съществува едно копие на файла. Основният проблем е ефективността, тъй като обменът с файл изисква както пренос на информация, така и обмен с диск.

Кеширане на паметта на сървъра. Два проблема са да кеширате цели файлове или дискови блокове и как да изскочите от кеша.

Разходите за комуникация остават.

Кеширането в машината на клиента ви позволява да се отървете от комуникациите.

Клиентското дисково кеширане може да не предлага никакво предимство пред кеширането на паметта на сървъра и сложността се увеличава значително.

Затова нека разгледаме по-отблизо организацията на кеширането в паметта на клиента.

• кеширане във всеки процес. (Добре е, ако един процес работи активно с файла - той отваря и затваря файла много пъти, чете и записва, например, в случай на процес на база данни).
• кеширане на ядрото. (режим на ядрото).
• кеш мениджър като отделен процес. (Ядрото е освободено от функциите на файловата система, но е трудно да се използва паметта ефективно на потребителско ниво, особено в случай на виртуална памет. Възможно е да се замразят страници, за да се избегне размяната на дискове).

Изборът на един или друг метод може да се оцени само като се вземе предвид естеството на приложенията и данните за скоростта на процесорите, паметта, дисковете и мрежата.

Кохерентност на кеша.

Алгоритъм за запис.
Необходимостта да се провери дали информацията в кеша не е актуална. Писането причинява комуникационни разходи (MS-DOS).

Алгоритъм за мързеливо писане.
Всички модифицирани блокове се записват във файла на редовни интервали. Ефективността е по-висока, но семантиката е неразбираема за потребителя (UNIX).

Алгоритъм за запис във файл при затваряне на файл .
Реализира семантиката на сесиите. Не много по-лош случайкогато два процеса на един и същи компютър отворят файл, четат го, променят го в паметта си и записват обратно във файла.

Централизиран алгоритъм за управление .
Може да се справи със семантиката на UNIX, но е неефективен, ненадежден и не се мащабира добре.

5.2.4 Възпроизвеждане

Системата може да предостави такава услуга като поддържане на множество копия за посочените файлове на различни сървъри. Основни цели:

1. Подобрете надеждността.
2. Увеличете наличността (сривът на един сървър не води до недостъпност на дублираните файлове.
3. Разпределете натоварването между множество сървъри.
4. Изрично размножаване (непрозрачно). В отговор на отваряне на файл на потребителя се представят множество двоични имена, които трябва да използва за изрично дублиране на файлови операции.
5. Мързеливо възпроизвеждане. Едно копие се създава на един сървър и след това автоматично създава (в свободното си време) допълнителни копия и гарантира, че те се поддържат.
6. Симетрично възпроизвеждане. Всички операции се извикват едновременно на множество сървъри и се изпълняват по едно и също време.

Протоколи за корекция.
Не е много добро решение просто да изпращате съобщения с операцията за коригиране на всяко копие, тъй като в случай на злополука някои копия може да останат некоригирани. Има два алгоритъма, които решават този проблем.

1. Основен метод за разпространение на копие. Един сървър е обявен за главен, а останалите - за подчинени. Всички промени във файла се изпращат на главния сървър. Първо актуализира своето локално копие и след това изпраща инструкции за корекция на подчинените сървъри. Всеки сървър може да прочете файла. За да се предпази от повреда на основния сървър, докато не бъдат завършени всички корекции, преди да се извърши корекцията на основното копие, основният сървър съхранява в стабилна паметкоригираща задача. Слабост - повредата на основния сървър предотвратява корекциите.
2. Метод на гласуване. Идеята е да поискате четене и запис на файл от много сървъри (запис - от всички!). Заявката може да получи одобрение от половината сървъри плюс един. В този случай трябва да има споразумение относно номера на текущата версия на файла. Това число се увеличава с едно с всяка корекция на файл. Можете да използвате различни стойности за кворума за четене (Nr) и за кворума за запис (Nw). В този случай съотношението Nr + Nw> N трябва да бъде изпълнено. Тъй като четенето е по-честа операция, естествено е да вземем Nr = 1. В този случай обаче всички сървъри са необходими за кворума за запис.

5.2.5 Пример: Мрежова файлова система на Sun Microsystems (NFS)

Първоначално пуснат на пазара от Sun Microsystem през 1985 г. за използване на техните UNIX-базирани работни станции. Понастоящем се поддържа от други доставчици за UNIX и други операционни системи (включително MS-DOS). Интересните аспекти на NFS са архитектура, протоколи и имплементация. NFS архитектура. Позволява ви да имате произволен набор от клиенти и сървъри на всякакви компютри в локална или мащабна мрежа.

Всеки сървър експортира определен брой свои директории за отдалечени клиенти за достъп до тях. В същото време се експортират директории с всичките им поддиректории, т.е. всъщност поддървета. Списъкът с експортирани директории се съхранява в специален файл, което позволява автоматичното им експортиране при стартиране на сървъра.

Клиентът осъществява достъп до експортираните директории, като ги монтира. Ако клиентът няма дискове, той може да монтира директории в основната си директория.

Ако няколко клиента са монтирали една и съща директория по едно и също време, те могат да споделят файлове в една и съща директория без допълнителни усилия. Простотата е добродетел на NFS. NFS протоколи. Тъй като една от целите на NFS е да поддържа хетерогенни системи, клиентите и сървърите могат да работят на различни компютри с различна архитектураи различни ОС. Затова е необходимо да има строги протоколи за тяхното взаимодействие. NFS има два такива протокола.
Първият протокол поддържа монтаж ... Клиентът може да изпрати разграничено име на директория (име на път) до сървъра и да поиска разрешение да го монтира. Къде клиентът ще монтира директорията за сървъра, няма значение и следователно не му се съобщава. Ако пътят е правилен и директорията е дефинирана като експортирана, сървърът връща дескриптора на директорията на клиента. Дескрипторът съдържа полета, които уникално идентифицират типа на компютъра, диска, номера на i-въртекса (концепцията на UNIX OS) за тази директория, както и информация за правата за достъп до нея. Този дескриптор се използва от клиента при последващи операции с директория.

Много клиенти монтират необходимите отдалечени директории автоматично при стартиране (с помощта на командна процедура на UNIX shell).

Версията Sun (Solaris) на UNIX има свой специален режим за автоматично монтиране. Всяка локална директория може да има множество отдалечени директории, свързани с нея. Когато се отвори файл, който не е в локалната директория, ОС изпраща заявки до всички сървъри (притежаващи посочените директории). Който отговори пръв, директорията ще бъде монтирана. Този подход осигурява както надеждност, така и ефективност (който е по-свободен, ще отговори по-рано). Това предполага, че всички алтернативни директории са идентични. Тъй като NFS не поддържа репликиране на файлове или директории, този режим на автоматично монтиране се използва главно за директории с програмни кодове или други рядко модифицирани файлове.

Вторият протокол е за достъп до директории и файлове. Клиентите изпращат съобщения, за да манипулират директории, да четат и записват файлове. Можете да получите файлови атрибути. Повечето от системни повиквания UNIX OS с изключение на ОТВОРЕНИ и ЗАТВОРЕНИ. За получаване на файлов дескриптор по символното му име се използва операцията LOOKUP, която се различава от отварянето на файл по това, че не се създават вътрешни таблици. По този начин сървърите в NFS са без състояние. Поради това се използва специален механизъм за заснемане на файла.

NFS използва механизма за защита на UNIX. В първите версии всички заявки съдържаха идентификатор на потребителя и неговата група (за проверка на правата за достъп). Няколко години работа на системата показаха слабостта на този подход. Сега се използва криптографски механизъм с публичен ключ за валидиране на легитимността на всяка заявка и отговор. Данните не са криптирани.

Всички ключове, използвани за контрол на достъпа, се поддържат от специална услуга (и сървъри) - мрежа информационна услуга(NIS). Чрез съхраняване на двойки (ключ, стойност), услугата осигурява издаване на стойността на кода при правилно потвърждение на ключовете. В допълнение, той осигурява съпоставяне на имена на машини с техните мрежови адреси и други съпоставяния. NIS сървърите използват схема главен-подчинен за реализиране на разпространение (мързеливо разпространение). Внедряване на NFS(XDR - Представяне на външни данни)

Целта на слоя на виртуалната файлова система е да поддържа за всеки отворен файл ред на таблица (v-възел), подобен на UNIX i-възел. Тази линия ви позволява да различавате локални файловеот дистанционно. За изтрити файлове, всички необходимата информациясъхранява се в специален r-възел в NFS клиента, който се препраща от v-възела. Сървърът няма таблици.

Прехвърлянето на информация между клиента и NFS сървъра се извършва в 8K блокове (за ефективност).

Има два кеша - кешът на данните и кешът на атрибутите на файла (те често са достъпни, разработчиците на NFS предполагат 90% рейтинг). Реализирана семантика на мързеливо писане - обект на критика на NFS.

Има и кеш за подсказки за ускоряване на получаването на v-върх със символно име. Когато използва наследения намек, NFS клиентът ще се свърже с NFS сървъра и ще актуализира кеша му (потребителят не трябва да е наясно с това).

Лаборатория за паралелни информационни технологии, Изследователски изчислителен център, Московски държавен университет

Разпределената файлова система (DFS) е конфигурирана на операционната система Windows 2000 Server ( Контролен панел – Администриране - DFS разпределена файлова система) и ви позволява да комбинирате файлови ресурси, разположени на различни компютри, в едно пространство от имена. По този начин, вместо мрежа от много машини, потребителят вижда структура на логическо име, свързана със споделени ресурси.

Предимства на DFS:

· Възможност за логично представяне на споделени ресурси, разположени на различни сървъри в мрежата;

· Удобно администриране на том - споделен дял, който е част от DFS том, може да бъде изключен без никакво въздействие върху останалата част от пространството от имена;

· Наличие на инструмент за графично администриране;

· Възможност за организиране на отказоустойчиви схеми за съхранение - едно логическо име може да съответства на няколко копия на ресурса (реплика), чието присъствие е прозрачно за потребителя;

· Балансирано натоварване на споделените мрежови ресурси чрез свързване на едно име на ресурс с различни реплики на този ресурс;

· Прозрачност на съответствието между логическото представяне на данните и тяхното физическо местоположение – потребителите не са наясно с промените във физическото местоположение на ресурса;

· Интеграция с модела за сигурност на Windows 2000 — използват се единни потребителски акаунти;

· Интелигентно кеширане на данни от страна на клиента;

· Възможност за взаимодействие с други мрежови файлови системи.

Необходимостта от разгръщане на разпределена файлова система може да възникне, когато в мрежата има множество файлови сървъри или, ако е необходимо, предоставяне на много потребители постоянен достъпкъм множество споделени ресурси.

Отправната точка за логическите имена на DFS дървото е коренразпределена файлова система, за създаването на която трябва да посочите някакъв дял, намиращ се на сървъра. Всички други имена на DFS ще бъдат на следващото йерархично ниво. Споделените компютърни мрежови ресурси в дървото на DFS са представени с логически имена, които се появяват на следното място в пълното име на ресурса в мрежата: \\ ServerName \ Логическо_DFS_Име \Път \ Файл.

DFS позволява до 32 алтернативни споделени ресурса (реплика) да бъдат съпоставени с едно логическо име. Ако репликите са вътре NTFS дял 5.0 на изградена разпределена файлова система Windows сървъри 2000 и интегрирани с Active Directory, можете да конфигурирате автоматична синхронизация за тях - съгласуване на данни (репликация). В други случаи трябва да се извърши съгласуване на реплика ръчно.

Елементите системна интеграция

В разпределени изчислителни системиили обществени компютърни мрежи като Интернет, има много обекти от интерес като бази данни, принтери, факс сървъри, приложения, потребители. Потребителите трябва да могат да намират и използват тези обекти. Администраторите трябва да управляват използването на тези обекти.

Услуга за справочник

Каталогът се нарича информационен ресурсизползва се за съхраняване на информация за обекти от интерес. Във файловите системи директорията съхранява информация за файловете.

Услугата на директории се различава от директорията по това, че е едновременно ресурс от данни и услуга, чрез която потребителите могат да имат достъп и да използват тези данни.

Услугата за справочник може да направи следното:

· Поддържайте нивото на сигурност, определено от администраторите, за да защитите данните от неоторизиран достъп.

· Разпространете каталога на различни компютри в мрежата.

Репликирайте директорията, за да осигурите достъп до нея Повече ▼потребители и повишаване на защитата на мрежата от повреди.

· Разделете директорията на няколко секции, за да осигурите възможност за съхранение на голям брой обекти.

Услугата за справочник е едновременно административен инструмент и инструмент за краен потребител. С нарастването на броя на обектите в мрежата, значението на услугата директория нараства. Услугата на директории е оста, около която се върти голяма разпределена система.

Active DirectoryТова е услуга за директории, включена в операционната система Windows 2000/2003 Server. Това е ясен пример за системна интеграция - разширява възможностите на вече съществуващите услуги за директории до Базиран на Windowsи добавя напълно нови функции.

Active Directory осигурява сигурност, разпространение, разделяне и репликация. Той е проектиран да бъде инсталиран на система от всякакъв размер – от един сървър с няколкостотин сайта до система от хиляди сървъри с милиони сайтове. Active Directory предоставя много нови функции, които улесняват намирането и управлението на големи количества данни и спестяват време както за администраторите, така и за крайните потребители.

Active Directory представлява пространство от имена, в което името на обект в директорията се разрешава до самия обект.

ПредметТова е отделен наименуван набор от атрибути, които представляват нещо конкретно — например потребител, принтер, приложение.

Атрибутисъдържат данни, описващи обекта, който е идентифициран от каталожния обект. Потребителските атрибути, например, могат да съдържат неговото име, фамилия и имейл адрес.

Клас обектдефинира типа информация, съдържаща се в Active Directory за екземпляри (обекти) от този клас... Следователно, всеки обект принадлежи, според поне, към един обектен клас, който е семейство от обекти с определени общи характеристики.

СхемаУслугата за директория на Active Directory се реализира като набор от екземпляри на обектен клас, които се съхраняват в директория. Следователно схемата е колекция (матрица) от всички атрибути и класове.

Контейнере подобен на обект с това, че има атрибути и е част от пространството за имена на Active Directory. Но той, за разлика от обект, не представлява нещо конкретно. Това е просто "обвивка" за група обекти и други контейнери.

Срок дървоизползва се за описване на йерархия от обекти и контейнери. Върховете на дървото обикновено са обекти. Възлите на дървото (точките, където клоните на дървото) са контейнери. Дървото показва връзката между обектите или пътя от един обект до друг. Простата директория е контейнер. Компютърна мрежаили домейн също са контейнери. Непрекъснато поддърво е всеки съседен път в дървото, включително всички съставки на всеки контейнер, включен в този път (Фигура 3.5).

Фиг.3.5. Непрекъснато поддърво на файловата директория

Името идентифицира всеки обект в услугата директория на Active Directory. Имената са два вида: отличително име и относително отличително име.

Отличително име(DN - различимо име) дефинира домейна, съдържащ обекта, както и пълния път през йерархията на контейнера, водещ до този обект. Типичното DN може да изглежда така:

/ O = Интернет / DC = COM / DC = Microsoft / CN = Потребители / CN = Джеймс Смит

Това DN идентифицира потребителския обект "Джеймс Смит" в домейна на Microsoft.com. Тук CN означава общо име. (фиг. 3.6)

Ориз. 3.6. Изграждане на отличителни имена

Относително отличително име(RDN - Relative Distinguished Name) на обект е частта от името му, която е атрибут на самия обект. В предишния пример RDN на потребителския обект "Джеймс Смит" ще бъде CN = Джеймс Смит. RDN на неговия родител ще бъде CN = Потребители.

Active Directory позволява на сложна корпоративна среда да работи ефективно, като предоставя следните възможности.

· Единно влизане онлайн... Потребителите могат да влизат в мрежата с едно потребителско име и парола и все пак имат достъп до всички мрежови ресурси (сървъри, принтери, приложения, файлове и т.н.), независимо от местоположението им в мрежата.

· Информационна сигурност... Контролите за удостоверяване и достъп до ресурси, вградени в Active Directory, осигуряват централизирана защита за вашата мрежа. Правата на достъп могат да бъдат дефинирани не само за всеки обект в каталога, но и за всяко свойство (атрибут) на обекта.

· Централизирано управление... Администраторите могат централизирано да управляват всички корпоративни ресурси. Рутинни задачиадминистрирането не е необходимо да се повтаря за множество мрежови обекти.

· Администриране с помощта на групови политики.Когато компютърът се стартира или потребител влезе в системата, изискванията на груповите политики са изпълнени; техните настройки се съхраняват в обекти на групови политики (GPO) и са "свързани" със сайтове, домейни или организационни единици. Груповите политики дефинират например правата за достъп до различни предметикаталог или ресурси, както и много други "правила" за работа в системата.

· Гъвкавост на промените... Услугата за справочник гъвкаво следва промените в структурата на една компания или организация. В същото време реорганизацията на директорията не е сложна и може да бъде опростена. В допълнение, услугата за справочник може да бъде свързана с интернет, за да взаимодейства с бизнес партньори и да поддържа електронната търговия.

· DNS интеграция... Active Directory е тясно свързана с DNS. Така се постига единство в наименуването на ресурсите. локална мрежаи глобална мрежаИнтернет, като по този начин улеснява свързването на мрежата на потребителя с интернет. Active Directory използва DNS като своя услуга за местоположение. Windows 2000/2003 имена на домейни са DNS имена на домейни.

· Разширяемост на директорията... Администраторите могат да добавят нови класове на обекти към схемата на каталога или да добавят нови атрибути към съществуващите класове.

· Мащабируемост... Active Directory може да обхваща един домейн, множество домейни, един контролер на домейн или множество контролери на домейн – тоест отговаря на нуждите на мрежи от всякакъв размер. Множество домейни могат да бъдат свързани в дърво на домейни и множество дървета на домейни могат да бъдат свързани в гора.

· Репликация на информация... Active Directory използва репликация на информация за услугата в схема с няколко главни, която ви позволява да модифицирате директорията на всеки домейн контролер. Множество контролери на домейни осигуряват отказоустойчивост и балансиране на мрежовото натоварване.

· Гъвкавост на заявките за каталог... Потребителите и мрежовите администратори могат бързо да намират обекти в мрежата, като използват свойствата на обекта (например потребителско име или имейл адрес, тип или местоположение на принтера и т.н.). Това, по-специално, може да се направи с помощта на командата Старт - Търсенепапка Моят мрежов кварталили щракнете Active Directory – потребители и компютриПроцедурата за търсене е оптимизирана чрез използването на глобалния каталог.

· Стандартни интерфейси... За разработчиците на приложения услугите на директории предоставят достъп до всички възможности (инструменти) на директорията и поддържат приетите стандарти и програмни интерфейси (API). Услугата на директории е тясно свързана с операционната система, за да се избегне дублиране в приложните програми функционалностсистеми, като оборудване за сигурност.

Основните компоненти на всяка услуга на директории е база данни, съдържаща необходимата информацияи един или повече протоколи за предоставяне на данни на потребителите. Active Directory осигурява съхранение за всяка публично достъпна информация. Подобно на други услуги за директории, Active Directory предоставя някакъв механизъм за съхранение на информация и протоколи за достъп до нея.

Можем да кажем, че услугата Active Directory "стои на три стълба":

Стандарт X.500

DNS (услуга за имена на домейни)

· LDAP протокол(Олекчен протокол за достъп до директория)

Active Directory частично реализира модела на данни, описан от стандарта X.500. Традиционно в TCP/IP мрежите DNS услугасе използва по-специално за намиране на контролери на домейни и благодарение на протокола LDAP клиентите могат да намерят в Активна директорияОбекти на директория и достъп до техните атрибути.

За да разберем структурата на Active Directory, нека първо разгледаме разликите между Windows 2000 и предишните версии на сървъра. операционна система Windows. Компютрите с Windows 2000 все още са групирани в домейни. Домейните са известно решениеза групово администриране, давайки на всеки потребител сметкав определен домейн. Въпреки това, за разлика от Windows NT Server 4.0, където на домейните са дадени прости низови имена (NetBIOS имена), в среда на Windows 2000 Server всеки домейн трябва да има име, което следва конвенциите за именуване на системата за имена на домейни (DNS). Например, домейн с име NetBIOS MainOffice може да получи ново име, като mainoffice.company.com, когато бъде актуализиран.

Във всеки домейн един или повече компютри трябва да действат като домейн контролери. В среда на Windows 2000 Server всеки домейн контролер съдържа пълно копие на базата данни Активни данниДиректория на този домейн.

Active Directory използва това, което се нарича Extended Storage Engine (ESE) и два различни протокола, които осигуряват комуникация между клиентите и базата данни.

За да намери контролер на домейн, клиентът използва протокола, описан в DNS, "стандартната" услуга за директории, която в момента се използва за TCP/IP мрежи.

Клиентът използва Lightweight Directory Access Protocol (LDAP) за достъп до данни в Active Directory (Фигура 3.7).

Фиг.3.7. Достъп до данни чрез LDAP

След използване Изисква се DNSе открит контролер на домейн и използва LDAP за достъп до данни на Active Directory. LDAP работи върху TCP / IP и - както подсказва името на протокола - дефинира как клиентите имат достъп до директорията.

В допълнение към механизма за достъп, този протокол изпълнява конвенции за именуване на информация в директорията, in изричноописвайки структурата на тази информация. За клиента всички данни, съхранявани в базата данни LDAP, се представят под формата на йерархично дърво. Всеки възел на дървото (обект или елемент) може да бъде или контейнер, или лист. Разликата между тях е съвсем очевидна: контейнерите могат да съдържат други елементи, но листата не.

Всеки елемент (контейнер или лист) е обектен клас, който дефинира атрибутите (наричани още свойства) на този елемент. Тъй като и контейнерите, и листата имат атрибути, информацията, съхранявана в дървото на директориите, се разпределя във всички възли.

Типът информация (класове на обекти и типове атрибути), съдържаща се в конкретна база данни на Active Directory, се диктува от схемата, дефинирана за тази директория. В Active Directory схемата на всяка директория е представена от елементи, съхранявани директно в самата директория. Microsoftдефинира стандартна схема, но потребителите и разработчиците софтуерни инструментиможе да добавя нови класове и типове атрибути. Промяна на схемата на директорията - полезна възможносткоето трябва да се използва много внимателно, тъй като подобни промени могат да имат много значителни последици.