SMB 3
ИТ инфраструктурата за вашето предприятие
Протокол блок съобщение сървър (SMB) в една или друга форма се използва при всяка организация за достъп до хранилището. Това може да има достъп до влизане скриптове, инсталиране на софтуер CD, или към документите, потребителски и MP3 музикални колекции. Когато не се прилага SMB, защото тя е в протокола за достъп до файла (тук клиента вместо директен достъп до блоковете на диска има достъп до файловете) при достъп до корпоративни приложения за външна памет. Що се отнася до обмена на данни със съхранението в производствената корпоративна среда, списъкът на олово блок технология (когато сървърът комуникира директно с блокове на диска), като ISCSI и на Fibre Channel (и евентуално, NFS за не-Windows бизнес приложения).
Когато един потребител се редактира документ Microsoft PowerPoint, се съхранява на SMB споделения ресурс, част от този документ се кешира на местно ниво, и от време на време потребителят натисне бутона "Save". Ако възникне проблем в сървъра за SMB файл, например свързани с рестартиране, или движението на споделена папка в друга клъстър (ако сървърът е част от една група), потребителят губи достъп до дескриптора на файла, но без никакви последствия. Следващият път, когато натиснете бутона "Save", всички възстановен, и нищо не е наред. А сега да разгледаме и Hyper-V виртуална машина, която се съхранява на SMB файл акция. Ако възникне проблем с приемащата споделен ресурс се премести в друга клъстър. Hyper-V TCP изчаква, докато времето за изчакване, след това установи грешка на първоначалното съединение. За една виртуална машина, това може да означава 30-секундна пауза. Въпреки това, Hyper-V е загубил дръжки VHD виртуален твърд диск, който е по-сериозен проблем. Ако продължителността на документи на потребителя може да бъде изчислено в рамките на няколко часа, корпоративните услуги, виртуални машини и бази данни изискват непрекъсната наличност на описания на файлове в продължение на много месеци.
прозрачен срив
По отношение на службите на корпоративни данни (например виртуални машини или бази данни SQL Server) SMB, като правило, не се използва от един файл на сървъра, и клъстер, който трябва да гарантира висока надеждност. При осъществяването на услуга клъстер файл на един от възли, обикновено се монтира логически номер обем LUN, съдържащ обща файлова система и дава достъп на клиентите SMB до споделянето на ресурси. При закриването на събранието LUN, монтиран на друг клъстер. В този случай, клиентът губи дескрипторите на SMB файлове.
Service SMB Прозрачен Failover осигурява защита срещу фалит възел. Преместването на споделен ресурс между възлите се извършва при пълна прозрачност за SMB клиенти, като им позволява да се запазят всички съществуващи файлови дескриптори и имат непрекъсната връзка SMB.
Съединение SMB поддържа между три обекта: SMB клиент SMB на сървъра и на диск, който съдържа данните. Прозрачен SMB гъвкавост осигурява съществуват достатъчни условия за предаване на съединение SMB алтернатива възел в случай на повреда, която позволява гладко изпълнява процеси в зависимост от SMB.
Въпреки това, дори прозрачен гъвкавост SMB Прозрачен Failover не изключва паузата в входно / изходни операции, когато LUN се монтира на друга клъстера. Група Failover Clustering разработчиците свърши страхотна работа за оптимизиране на демонтаж и монтаж на LUN, намаляване на максималната продължителност на процедурата, до 25 секунди. Изглежда от дълго време, но това се отнася и за най-неблагоприятното сценарий с участието на голям брой логически единици и десетки хиляди тагове. За най-често срещаните случаи, тази процедура ще се извършва за няколко секунди и корпоративни услуги, като Hyper-V и SQL Server, може да обработва 25-секундна пауза в I / O, без никакви грешки.
Друга възможна причина за почивката във входната подсистема / изхода - липса на информация за сървъра за SMB клиент SMB е недостъпен. В типичен сценарий (например, когато един възел рестартира след инсталирането на кръпка), сървърът уведомява клиента за това, което се случва, и те могат да предприемат необходимите действия. Но катастрофа приемни клиентите не получават известия. В този случай, клиентът изчаква, докато времето за изтичане на TCP, преди да вземе мерки, за да възстанови връзката, което означава загуба на ресурси. SMB клиент не може да знае, че възелът, с които взаимодейства, в ред, но и други възли в клъстера знаят за него по-малко от секунда, благодарение на доклади IsAlive синхронизация обменят между възлите.
Клиент SMB - Сървър A: «Искам да се установи връзка".
Сървър A: е установено «връзка. Аз съм част от клъстера, който също има сървъри B, C и D ».
SMB Клиент - Сървър Б: «Аз съм установил връзка към SMB сървър А. Моля, спазвайте сървър и ме уведоми в случай на повреда".
Сървър Б: «OK. Приятен ден. "
