Високата наличност е това, което обича да демонстрира в цифри. Всеки вече е свикнал маркетинг ход А достъпността на 99% изглежда просто фантастично висока. Само малка част от клиентите разбират, че достъпността на 98-99% е много лоша, няма подходящи на места навсякъде.

Погледнете тези цифри и ще разберете каква достъпност е 90% различна от достъпността 99.99%:

Наличност	Празно време на месец	Престой годишно
90%	3 дни	37 дни
98%	14.6 часа	7.3 дни
99%	7.3 часа	3.7 дни
99,8%	1,5 часа	18 часа
99,9%	44 минути	8.8 часа
99,99%	4.4 минути	53 минути
99,999%	26 секунди	5.3 минути

Гледайки масата по-горе, разбирате, че центърът за данни, който гарантира достъпността на мрежата в 99%, може да осигури 7 часа време на празно обслужване на месец. Представете си такава ситуация: целият ден в центъра за данни е нещо, което трябва да се спечели, вашият сайт не е на разположение, вие сте загуби и не можете да представите иск към Центъра за данни - дори и с тази ситуация, тя ще осигури обещана достъпност.

Смятам, че достъпността на мрежата 99% е лоша. Предпочитам центрове за данни, които осигуряват най-малко 99,9% от наличността на мрежата.

Вероятно има интернет проекти, които могат да оцелеят и 37 дни на безделие годишно (повече от месец!). Но всички същите онлайн пазаруване, портали и сайтове (особено тези, чиито транзакции преминават през обекта), не могат да си позволят такъв лукс, като дори 18 часа годишно. Винаги е трудно да се възстанови репутацията и ако се загуби поради причините "в системния администратор на продукцията", това изобщо не е.

"Пет девет" - това е, което е висока наличност

Терминът "пет деветки" означава наличността от 99.999% и се случва в маркетинговата литература най-малко в технически. Смята се, че сайтът или системата с нивото на наличност "пет деветки" е висока наличност.

Необходима е висока наличност за всички

Тя може да се види от таблицата, че 99.9999% от наличността е само 5,3 минути на празно време годишно. Но дори тези центрове за данни, които гарантират 100% наличност, често се започват с маркетингови трикове.
Например, времето ще се приспадне регулаторна служба От времето на наличността. Например, центърът за данни обещава достъп до 99.99%, но в момента, в който планираната работа се извършва на заместването на нещо, пише " регламенти В рамките на 2 часа, "и не го смята за недостъпност. Оттук и договора за прочетено обслужване (SLA) внимателно.

Ако искате да предоставите най-високата наличност на сайта си на един Server, изберете Центъра за данни с достъпност за добро гарантирано SLA (споразумение за ниво на обслужване).

Забележка! SLA трябва да бъде гарантиран да замени дефектното желязо. И, в идеалния случай, времето за отговор на проблема.

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

Малко за това, което е високата наличност

Наличността може да бъде мрежа и обслужване.

Достъпност от мрежата - Това е, когато сървърът ви е достъпен в мрежата.
Наличност на услуга - Това е, когато вашият сървър може да обслужва клиенти.

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

Наличността на услугата зависи от:

• наличност на мрежата на вашия сървър
• скоростта на реакцията на вашия администратор по проблема
• скоростта на подкрепа за подкрепата на центъра за данни по проблема
• замяна на дефектното желязо в центъра за данни

Недостъпност гънки от:

• въпроси за достъпност на мрежата
• проблеми с "желязо"
• проблеми с товара на сървъра ("забавя", не се справя)
• софтуерни грешки (програмисти "Shoal")

И месечните (с изключение на случаите на повреда на желязо) и още по-голяма наличност на 99,8% може да бъде предоставена в добра DC на един сървър без допълнителни мерки за толерантност. Наличността на 99,9% вече изисква късмет.

Ако имате нужда от гарантирана наличност над 99,8%, е необходимо да се справите с толерантността към грешки. И сървърът не трябва да е такъв. Но това е темата на отделен разговор.

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

Ще ви кажем какви са начините за защита на неуспехите на сървърите и кои архитектури се използват при прилагането на облака VMManager: Продукт, който е предназначен да създаде висок клъстер за достъпност.

Предговор

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

• Толерантност към неуспеха (толерантност към неизправност, FT) - способността на системата да работи допълнително след провала на някой елемент.
• Клъстер - група сървъри (изчислителни единици), комбинирани комуникационни канали.
• Толерантен клъстер, FTC - клъстер, отказ на сървър, в който не води до пълната неработемост на целия клъстер. Задачите на неуспешната машина се разпределят между един или няколко останали възли в автоматичен режим.
• Непрекъсната наличност (непрекъсната наличност, СА) - Потребителят може да използва услугата по всяко време, не се появяват прекъсвания. Колко време е преминало, откакто повредата на възела няма значение.
• Висока наличност (висока наличност, ха) - в случай на повреда, потребителят няма да получи услуга за известно време, но възстановяването на системата автоматично ще се осъществи; Времето на Даут е сведено до минимум.
• Клъстер на KND - непрекъсната достъпност, CA-клъстер.
• QW - Клъстер с висока наличност, ха-клъстер.

Нека бъде необходимо да се разгърне клъстер от 10 възли, където на всеки възел се стартират виртуални машини. Има задача за защита на виртуалните машини от повреди на оборудването. За да увеличите изчислителната плътност на рафтовете, е решено да се използват две процесорни сървъри.

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

Непрекъснато наличност / непрекъсната наличност

Непрекъснатото обслужване на клиентите е възможно само ако има точно копие на сървъра (физически или виртуални), на които се изпълнява услугата по всяко време. Ако създадете копие след повреда на оборудването, ще отнеме време, което означава, че ще бъде в предоставянето на услуги. В допълнение, след счупване, ще бъде невъзможно да се получи съдържанието оперативна памет От проблемна кола, което означава, че информацията, която е загубена там, ще бъде загубена.
За да приложите CA, има два начина: хардуер и софтуер. Ще разкажем за всеки от тях малко повече.

Хардуер метод Това е "разделен" сървър: всички компоненти са дублирани и изчисленията се извършват едновременно и независимо. Синхронността е отговорна за възела, който наред с други неща се проверява от резултатите от половинки. В случай на несъответствия, причината за причината и опита за коригиране на грешка. Ако грешката не е настроена, дефектният модул е \u200b\u200bизключен.
HABRÉ наскоро бе на тема на хардуерни сървъри. Производителят, описан в материала, гарантира, че годишното празно време е не повече от 32 секунди. Така че, за да се постигнат такива резултати, трябва да закупите оборудване. Руският партньор на Стратус съобщи, че цената на CA сървър с два процесора за всеки синхронизиран модул е \u200b\u200bоколо $ 160,000 в зависимост от конфигурацията. Общо за клъстера ще се нуждаят от $ 1,600,000.

Софтуер.
По време на писането на статията най-популярният инструмент за разгръщане на групата непрекъсната наличност е от VMware. Технологията за непрекъсната достъпност в този продукт се нарича "толерантност на грешки".

За разлика от метода на хардуера, тази опция има ограничения за използване. Ние изброяваме главния:

• На физическия хост трябва да има процесор:
  • Intel архитектура пясъчен мост (или по-нов). Avoton не се поддържа.
  • AMD Bulldozer (или по-нова).
• Машините, които използват толерантност към неизправности, трябва да се комбинират в 10-гигабитска мрежа за забавяне. VMware силно препоръчва специална мрежа.
• Не повече от 4 виртуални процесора на VM.
• Не повече от 8 виртуални процесора на физическия гостоприемник.
• Не повече от 4 виртуални машини на физическия гостоприемник.
• Невъзможно е да се използват снимки на виртуални машини.
• Не може да се използва съхранение vmotion.

Има пълен списък на ограниченията и несъвместимости.
Експлоантно се установява, че технологията на толерантността на неизправностите от VMware значително "забавя" виртуална машина. По време на изследването на VMGU.RU след включване на FT производителността на VM при работа с базата данни спадна с 47%.

Лицензирането на VSphere е свързано с физически процесори. Цената започва с $ 1750 за лиценз + $ 550 за годишна абонамент и техническа поддръжка. Също така, се изисква VMware VCenter сървър за автоматизиране на контрола на клъстера, който струва от $ 8,000. Тъй като 2N схемата се използва за осигуряване на непрекъсната наличност, за да работи 10 възли с виртуални машини, трябва допълнително да закупите 10 дублирани сървъра и лицензи за тях. Общата цена на програмата на клъстер ще бъде 2 * (10 + 10) * (1750 + 550) + 8000 \u003d $ 100 000.

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

Заслужава си да споменем за тези продукти, чието развитие спря.

Има Remus, базиран на Xen, свободен отворен код. Проектът използва технология microsnapps. За съжаление, документацията не е актуализирана за дълго време; Например, инсталацията е описана за Ubuntu 12.10, чиято подкрепа е преустановена през 2014 година. И достатъчно странно, дори Google не намери компания, която прилага Remus в своята дейност.

Опитите за усъвършенстване на QEMU, за да добавите способността да създадете непрекъсната наличност на клъстера. По време на това писане има два такива проекта.

Първият е Kemari, продукт с отворен код, управляван от Йошиаки Тамура. Тя е предназначена да използва механизмите на живата миграция на QEMU. Въпреки това, фактът, че последният ангажимент е направен през февруари 2011 г., казва, че най-вероятно развитието е влязло в задънена улица и няма да се възобнови.

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

По този начин, прилагането на непрекъсната наличност, основана на виртуализацията на KVM, в момента не е така.

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

Висока наличност / висока способност

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

QW не синхронизира процесите, работещи върху възли и локалните дискове на машините не винаги са синхронизирани. Преди възлите, използвани от възли, трябва да бъдат на отделно независимо съхранение, например, при съхранение на мрежови данни. Причината е очевидна: в случай на провал, възелът ще се провали с него, което означава, че няма да има възможност за достъп до информация за нейното съхранение. Естествено, SCD също трябва да бъде толерантен към грешките, в противен случай QW не работи по дефиниция.

По този начин, клъстерът с висока наличност е разделен на две подклик:

• Изчислителни. Тя включва възли, върху които директно пускат виртуални машини.
• Клъстер за съхранение. Има дискове, които се използват от възли на компютърния подклап.

В момента, за внедряване на KVD с виртуални машини за възли има следните инструменти:

• Сърдечна версия 1.x във връзка с DRBD;
• Пейсмейкър;
• VMware vsphere;
• Proxmox ve;
• Xenserver;
• Openstack;
• яйцеклетка;
• Red Hat Enterprise виртуализация;
• Изтичане на сървъра на Windows сървъра в сноп със сървърната роля "Hyper-V";
• Vmmanager облак.

Ще ви запознаем с особеностите на нашия продукт VMManager Cloud.

Vmmanager облак.

Нашият облак VMManager облак използва виртуализация на QEMU-KVM. Направихме избор в полза на тази технология, защото тя активно се разработва и поддържа, а също така ви позволява да инсталирате всяка операционна система на виртуалната машина. Corosync се използва като инструмент за идентифициране на неуспехи в клъстера. Ако някой от сървърите се провали, VMManager последователно разпространява виртуални машини на останалите възли.

В опростена форма алгоритъмът е:

1. Клъстерният възел се намира с най-малкия брой виртуални машини.
2. Заявката е изпълнена. Има достатъчно безплатна RAM, която да постави текущия VM в списъка.
3. Ако паметта за разпределената машина е достатъчно, VMManager дава командата да създаде виртуална машина на този възел.
4. Ако паметта не е достатъчна, търсенето се извършва на сървъри, които носят повече виртуални машини.

Проведохме тестването на много конфигурации на желязо, интервюирани съществуващи потребители на облака VMManager и въз основа на получените данни, заключавайки, че за разпределението и възобновяването на всички VM от неуспешния възел, той отнема от 45 до 90 секунди в зависимост от скоростта на оборудването.

Практиката показва, че е по-добре да се разграничат един или повече възли за извънредни ситуации и да не ги разгръщат в работата по време на работа. Този подход изключва ситуацията, когато "живите" възли в клъстера нямат ресурси за поставяне на всички виртуални машини с "мъртвите". В случай на един резервен сървър, схемата за резервация се нарича "n + 1".

Облакът VMManager поддържа следните типове хранилища: файлова система, LVM, мрежа LVM, Iscsi и Ceph. В контекста на QW се използват последните три.

При използване на вечния лиценз, цената на програмата част от клъстера от десет "бойни" възли и един архив ще бъде € 3520 или $ 3865 днес (лицензът струва 320 евро за възел, независимо от броя на процесорите върху него ). Лицензът включва годината на безплатни актуализации и от втората година те ще бъдат предоставени като част от пакета за актуализиране на стойност 880 евро годишно за целия клъстер.

Помислете за това какви схеми VMManager Cloud са внедрили клъстери с висока достъпност.

Първи.

Първо започна да предоставя облак хостинг през февруари 2016 година. Първоначално клъстерът работи под Openstack. Въпреки това, липсата на достъпни специалисти по тази система (както в присъствието, така и в цената) подтиква търсенето на друго решение. Следните изисквания бяха представени на нов инструмент за управление на QWD:

1. Способността да се осигурят виртуални машини на KVM;
2. Присъствието на интеграция с цеп;
3. Наличие на интеграция с фактуриране, подходящо за предоставяне на налични услуги;
4. Налични разходи за лицензии;
5. Наличието на подкрепа за производителя.

В резултат на това облакът VMManager се приближи до най-доброто за изискванията.

Отличителни характеристики на клъстера:

• Предаването на данни се основава на Ethernet технология и се изгражда на Cisco оборудването.
• Cisco ASR9001 отговаря за маршрута; Клъстерът използва около 50 000 адреса на IPv6.
• Скорост на връзката между изчислителните китове и 10 GB / s превключватели.
• Между ключовете и кимването на склада се използва степента на обмен на данни от 20 gb / s, агрегирането на два канала от 10 GB / s.
• Между стелажите със складови възли има отделна 20-гигабитна връзка, използвана за репликация.
• В възлите за съхранение, SAS устройствата са инсталирани заедно с SSD устройства.
• Тип на съхранение - Цен.

В общ Системата изглежда така:

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

FirstVds.

FIRETVDS осигурява неудобно-толерантна хостинг услуга, стартирането на продукта се състоя през септември 2015 г.

За да използвате облачната компания VMManager, идва от следните съображения:

1. Богат опит с продуктите на ISPSystem.
2. Наличието на интеграция с BillManager по подразбиране.
3. Отлично качество на технологичните поддържащи продукти.
4. CEPH поддръжка.

Клъстерът има следните характеристики:

• Предаването на данни се основава на Infiniband мрежи със скорост от 56 GB / s;
• Infiniband-мрежа, изградена върху оборудване на меланокс;
• В складовите възли инсталирани SSD носители;
• Използван тип съхранение - цеф.

Общата схема изглежда така:

В случай на обща недостатъчност на Infiniband-Network, връзката между съхранението на VM и изчислителните сървъри се извършва чрез Ethernet мрежа, която е разположена на хвойна. "Вземане" се случва автоматично.

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

Епилог

Нека обобщим статията. Ако всеки втори прекъсване на услугата носи значителни загуби - не се извършва без група от непрекъсната наличност.

Въпреки това, ако обстоятелствата ви позволяват да изчакате 5 минути, докато виртуалните машини се разгръщат на резервния възел, можете да погледнете към QW. Тя ще даде спестявания в цената на лицензите и оборудването.

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

Дефиниции

Всеки знае, че Microsoft Exchange DAG е "група за наличност на база данни" - "група за наличност на база данни".

База данни — защото нивовисока достъпност Сървър exchange 2010 пощенски кутии, се определя от базата данни, а не сървъра, това е базата данни е единицатакоето може да се движи между множество сървъри в рамките на групи за наличност на база данни в случай на повреда. Това принцип известява Как мобилността на базата данни.

Група - защото се определя площта на наличността пощенски кутии сървъри в група за достъпност на групата Юнайтед Б. клъстер за отказ И работят заедно като група.

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

Уикипедия определя "Наличност" като обозначение една от следните действия:
Степента, в която системата, подсистемата или оборудването е в определеното работно състояние, случай на повреда е поне неизвестен, т.е. Случайно време. Просто казано , наличност дял от времето, когато система намира се в състояние функциониране. Математически Тя се изразява в 1 минус недостъпност.
Връзка (а) общо време функциониране по време на посоченото Интервал до (б) величината на интервала.

В полза на теории за вероятност, това определение Означава същото: вероятността Тази система или компонент "в работно състояние" във всеки произволен момент време.

Математически може да се измерва Чрез преброяване на времето, когато системата е налична ("работно време") за някои Голям статистически представителен период (Обикновено години) и го разделя за общата продължителност на периода. Използване на широко прието време средно време между неуспехите (MTBF - средно време между неуспехи) и средно време на обслужване (Mttr - средно време за ремонт) - въведена системна достъпност./ Работа между неуспехи, престой на системата за дадено неуспех - наличност може да се изрази катофракция:

. \\ T Математическите характеристики ще бъдат вероятност за отказ:

Наличност често изразени като "Брой девет", в съответствие със следната таблица:

Ниво на наличност	Значение на достъпността	Вероятност за отказ	Допустимо време на годината
Две девет	99%	1%	5256 минути \u003d 3.65 дни
Три девет	99.9%	0.1%	525.6 минути \u003d 8.76 часа
Четири деветки	99.99%	0.01%	52.56 минути
Пет девет	99.999%	0.001%	5.26 минути

Разбира се, стойността на наличността ще бъде различно в зависимост от Считаме ли се планиран(планирани) и непланирани (непланирани) престой или само непланиран престой. Споразумение за ниво на обслужване (SLA)които изразяват бизнес изисквания Наличността трябва да съдържа конкретна информация. Но във всички случаи Наличност на това или това системи или компонент зависи от много фактори, I. изключително важно определят и разбират Тези зависимости I. как се отразяват Наличност.

Ефекта от зависимостите на пристрастяването

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

За дадено бази данни за пощенска кутия, следните компоненти може да се счита за как критични зависимости:
подсистема на диска База данни / система за съхранение - например A1;
пощенска кутия сървър (като хардуер, така и софтуерни компоненти) - А2;
от averver клиентски достъп (Хардуер I. софтуер Компоненти) - Не забравяйте, че в замяна на 2010 всичко клиентите са свързани с К. база данни за пощенска кутия само през Сървър за достъп на клиента (сървър с роля за достъп до клиента), и да приемем че CAS е инсталиран отделно от Сървърни сървъри по пощенска кутия - A3;
мрежова връзка между клиенти I. Сървър за достъп до клиента и между сървъра клиентски достъп и пощенски кутии за сървър - А4;
Електричество в центъра за данникъдето се намират сървърите и системи за съхранение - А5.

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

Защото тези компоненти сами поотделно независимо един от другприсъствието на всяка от тях представлява независим Събитие и полученото ниво на достъпност на базата данни обмен на пощенски кутии представлява комбинация всички тези събития (с други думи, за да база данни за пощенска кутиято е на разположение за Клиенти всички тези неща компоненти На разположение). На теории за вероятностВероятност за комбинация независими събития това е продукт Отделни вероятности за всяко събитие:

Например, ако хвърлите три монети, вероятност за изпадане "Eagle" за всичките три монети (1/2) * (1/2) * (1/2) \u003d 1/8.

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

Това може да бъде илюстрирано На представения пример в следващата таблица (Цифри са примери):

Критична зависимост.	Вероятност за отказ	Ниво на наличност
Система за сървъри и съхранение на пощенска кутия	5%	95%
Сървър за достъп до клиента	1%	99%
Нетна	0.5%	99.5%
Храна	0.1%	99.9%
	6.51383%	95% x 99% x 99.5% x 99.9% \u003d 93.48617%

От този пример, може да види как критично важни зависимости влияе върху наличността на услугата. Дори и за бази данни за пощенска кутияче никога неуспех (не ще бъдат повредени, никога не получавайте кошница вирусни инфекции и т.н.), достъпност още е останало под 93,5%!

Заключение: Голям брой Зависимите за услугите намаляват достъпността.

Всичко, което правим намаляване на номера или зависимости за експозиция положителен ефект на цяло наличност на услуга. Например , можем да се подобрим Ситуация чрез опростяване I. Имот управление на сървъра и оптимизация оперативни процедури. От техническата страна, ние можем да се опитаме намаляване на количеството Зависимост на услугите чрез нашия дизайн по-лесно - например, елиминиране на сложни системи за съхранение на базата на сан, влакнести превключватели, контролери на масиви и дори рейд контролери и го заменят с просто DAS с минимум движещи се части.
Намаляването на зависимостите на обслужването сам по себе си не може да бъде достатъчно донесете достъпност до желаното ниво. Още един много ефективен метод Увеличаване на достъпността I. въздействие върху минимум Критични зависимости лежи в привличането различни методи Резервации като използване два източника на енергия, комбиниране на мрежови карти, свързващи сървъри До няколко мрежови превключвателиИзползване на RAID за операционна система , разполагането на хардуерно балансиране за сървъри клиентски достъп I. множество копия бази данни за пощенска кутия. Но как точно увеличаването на съкращенията позволява ви да постигнете висока наличност? Нека повече подробности Обмисли балансиране на товара I. няколко копия на базата данни колкото и важно примери.

Как влияят на наличността

Концептуално всички методи за резервация означават едно нещо: да повече от едно копие компонент, който е наличен и може да се използва едновременно (както при товара балансиращи) или като заместител (както в случай на няколко копия на базата данни). Да приемем Имаме N. случаи на това Компонент (N сървъри в CAS, или N масив копия бази данни в DAG). Дори ако някой от тях не успява Други може да се използва за висока достъпност. Единствената ситуация Когато се сблъскваме с действителните неуспехи в обслужването, когато всички случаи спрет да бъдат достъпни.

Както е определено по-рано, вероятност за отказ за всеки този случай P \u003d 1 - А. Всички екземпляри статистически независим един от друг какво означава това производителност или неуспехвсеки от тях не засяга достъпността в други случаи. Например, неуспех копия база данни Не засяга вероятност за отказ За друго копие тази база данни (Възможен е логически нюанс, когато повреденото копие ще разпространява промени в други копия, но нека игнорирайте това Фактор - Б. в крайна сметкаВинаги можете да използвате мъртво копие на базата данни или опция за възстановяване. традиционно архивиране).

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

Очевидно, както Пс.< 1, Р н. по-малко Пс.Какво означава това вероятност за отказ намалява и съответно, достъпността се увеличава:

Помислете за някои истински пример за живот за яснота. Да речем това, което инсталираме Множество копия бази данни за пощенска кутияШпакловка Всяко копие е поставено на един SATA диск. Според статистиката процентът на неуспехите на SATA е ~ 5% за една година, което ни дава 5% вероятност за отказ: Р \u003d 0.05 (което означава наличието на 95%: a \u003d 0.95). Как да промените достъпността както се добавя копия база данни? Нека погледнем следваща таблица:

Брой копия	Вероятност за отказ	Ниво на наличност
1	P 1 \u003d p \u003d 5%	A 1 \u003d 1 - p 1 \u003d 95%
2	P2 \u003d P2 \u003d 0.25%	А 2 \u003d 1 - P2 \u003d 99.75%
3	P 3 \u003d p 3 \u003d 0.0125%	А 3 \u003d 1 - p 3 \u003d 99.9875%
4	P 4 \u003d P 4 \u003d 0.000625%	4 \u003d 1 - P 4 \u003d 99.9994%

Е впечатляващо? По принцип, всеки допълнителен екземпляр Бази данни за SATA диск въвежда коефициентно умножение 5% или 1/20, толкова вероятност неуспехът става 20 пъти по-нисък, с всяко копие (и съответно, Наличността се увеличава). Можем да видим, че дори и на най-ненадеждни SATA дискове, прилагане само 4 копия бази данни Ни води наличност на база данни В пет девет.
то вече много добър, но може ли да По-добре? Можем ли увеличаване на достъпността Все още без вземане архитектурни промени (например, когато добавяте друг копия база данни)?

Всъщност можем. Ако подобрим индивидуалната достъпност всеки компонент зависимостта увеличение на фактора обща достъпност Услуга, I. ще доведе до много по-силен ефект от от добавяне излишък от компонент. Например, един от възможните начини за това, се използва SAS дискове вместо сата дискове. Братко SAS дисковете имат годишно ниво на неизправност ~ 2.75% вместо ~ 5% за SATA. Това ще намали вероятност за отказ за компонента за съхранение и следователно ще увеличи цялостното наличност на услуга. Съвсем сравнено Ефект от допълнения на няколко копия база данни:
5% коефициент AFR \u003d 1/20 \u003d Умножаване на всяко ново копие прави щети Бази данни 20 пъти по-рядко.
2.75% AFR \u003d 1/36 коефициентно умножение \u003d всяко ново копие прави щети Бази данни 36 пъти по-рядко.

то значително влияние върху. \\ Tналичност на базата данни Също така обяснява инструкциите за използване на концепцията за собствена защита на обменната защита на данните, която обяснява, че могат да бъдат няколко копия от базата данни замяна на традиционните резервни копия, ако се разширяват достатъчен брой (три или повече).

Същата логика е приложима да се разположете няколко. сървъри за достъп до клиента В масива на CAS, няколко мрежови превключватели и т.н. Да предположим, че ние 4 копия на базата данни и 4 разположени 4 сървъри за достъп до клиентаи да се върнем към компонента на таблицата за достъпност, която анализирахме по-рано:

Критична зависимост.	Вероятност за отказ	Ниво на наличност
Сървър и съхранение на пощенска кутия (4 копия)	5% ^ 4 = 0.000625%	99.999375%
Сървър за достъп на клиента (изключени 4 сървъри)	1% ^ 4 = 0.000001%	99.999999%
Нетна	0.5%	99.5%
Храна	0.1%	99.9%
Обща стойност (в зависимост от всички тези компоненти)	0.6%	99.399878%

Ние може да види какво Само стартирахме 4 сървъри за достъп до клиента и 4 копия бази данни, вероятност за отказ Общата услуга е намаляла с повече от 10 пъти (от 6.5% до 0,6%) и съответно, наличие на услуги от 93,5% до много по-достойна стойност 99,4%!

Заключение: Добавяне на резервиране за зависимости подобрява достъпността.

Свържете заедно

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

В първия сценарий, сървъри по пощенска кутия са независими I. Те няма да бъдат достъпни само ако и двете сървъри се провалят. Вероятността за неуспех Набор от две. сървъри по пощенска кутия ще бъде Пс.× Пс. = Пс. 2. Съответно, неговата наличност ще бъде MBX. = 1 – Р 2.. Следвайки същата логика, CAS услуга няма да бъде недостъпен само ако и двамата сървъри клиентски достъп без ред следователно, вероятност неуспех за набор от две сървъри за достъп до клиента Ще бъде отново Пс.× Пс. = Пс. 2 и съответно, Неговата достъпност ще бъде CAS. = 1 – Р 2..
В този случай, както вече разбираме, две сървъри по пощенска кутия или два сървъра клиентски достъп са примери излишък компоненти на системата.
Продължаваме този сценарий. За да е налице цялата система, и двата набора от сървъра (набор от сървъри по пощенска кутия и комплект сървъри за достъп до клиента) трябва да е наличен По същото време. Не да се провалят едновременноно в същото време защото сега те представляват системен зависимости, но не излишните компоненти. Това означава, какво по принцип наличност на услугата това е продукт Наличноствсеки набор:

Сигурен, втори вариант много по-лесно както съществува само един сървър и обмисли неговата достъпностпросто А. = 1 – Пс..
И така, сега ние изчислени значения наличност за двата сценария. Z. гневът на който по-горе, (1-Пс. 2 ) 2 или 1-Пс.?

Ако Build. графика и двете функции, ще видим следващо поведение:

Виждаме, че за малка стойност p, наличието на цялостна система от 4 сървъра е по-висока, отколкото от присъствието на един сървър. Няма нищо изненадващо, това е, което очаквахме, нали? Въпреки това, при р ~ 0.618 - два части се пресичат и при големи стойности на p една система Сървърите всъщност имат по-висока наличност. Разбира се, вероятно ще очаква, че стойността на p трябва да бъде много близка до нула реалния живот. Въпреки това, ако планираме да създадем собствено решение от много ненадеждни компоненти, вероятно е решението под формата на един сървър да бъде по-добро.

Влиянието на критичните точки

За съжаление, описаните по-горе сценарии за разгръщане са рядкост в реалния живот. Например как ще повлияе на промяната в наличността, подлежи на внедряване на сървър с множество роли? Забелязахме, че в горния пример комбинацията от сървърни роли ефективно намалява броя на зависимостите на услугите, така че е вероятно всичко да бъде добре? И какво се случва, ако поставим две копия на базата данни от една база данни на една и съща масив SAN или DAS? Какво ще стане, ако всички сървъри на пощенски кутии са свързани към един мрежов превключвател? Ами ако имаме всичко по-горе и много повече?

Всички тези ситуации са изправени пред нас с концепцията за точка от отказ. В горните примери на сървърното оборудване или San масив или мрежов превключвател има точки на повреда. Точката на повреда нарушава независимостта или излишъка на компонентите, които съчетава - например, неуспехът на компонентите на сървърното оборудване в сървър с комбинация от роли означава, че всички роли на този сървър няма да бъдат достъпни; Съответно, отказът на диск или San масив означава, че всички копия на базите данни, поставени на този диск или масив, стават недостъпни.

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

Сценарий на сървъра с многовес

Нека да сравним наличието на две различни системи:
1. Rolstery на сървъра за сървъри по пощенската кутия и сървъра за достъп, разположен на същия сървър, който има вероятност от хардуерни неуспехи P;
2. В същите роли се публикуват на два отделни сървъра, всяка от които има същата вероятност за повреда на оборудването.

В първия случай хардуерът на един сървър е точка на повреда. Това означава, че всички командировани роли са налични или недостъпни. Това е просто, като цяло, наличността на такава система А \u003d 1 - P.

Във втория случай, като цяло, услугата ще бъде достъпна само когато и двата сървъра са достъпни независимо (защото всяка роля е критична зависимост). Ето защо, въз основа на теорията на вероятностите, нейното присъствие ще бъде × A \u003d A2.

Отново, като a<1, это означает, что A2 < А, так во втором случае доступность будет ниже.

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

Заключение: Поставянето на ролите на сървъра за обмен на сървъра с много колело увеличава цялостната наличност на услугите.

Сценарий за общо съхранение

Сега нека да разгледаме друг сценарий за повреда (две копия на базата данни за обмен на една масив) и сравняваме наличността на базата данни в следните два случая:

1. Копия от бази данни, поставени на същото съхранение (SAN или DAS), което има вероятност за P;
2. В същите копия на бази данни, поставени на две отделни системи за съхранение, всеки от които има същата вероятност за повреда.

В първия случай общото съхранение е отказа. Както и в предишния сценарий, това означава, че и двете копия на базата данни са налични или не са налични по едно и също време, така че общото ниво на наличност отново a \u003d 1 - p.

Във втория случай, като цяло, услугата ще бъде достъпна, ако е налична и недостъпна само ако и двете системи се провалят. Системите за съхранение са независими. Следователно, вероятността за неуспех обща служба P × P \u003d P2 и съответно общата наличност на услуги е A \u003d 1 - P2.

Отново, ако p< 1, то это означает, что Р2 <Р, и, следовательно, 1 – P2 > 1 - P. Това означава, че нивото на наличност във втория случай е много по-високо.

Заключение: Поставянето на копия на една база данни на една и съща система за съхранение намалява общата наличност на услугите.

Така че каква е разликата между тези два сценария, защо въвеждането на точки на повреда увеличава наличността в първия случай и намалява наличността в друга?

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

Всички тези концепции и заключения могат да бъдат представени в следната форма:

Заключения

Архитектура на Exchange 2010. осигурява мощно способности за добавяне съкращаване (например, разположете няколко. копия база данни или множество сървъри за достъп до клиента в масив CAS.) и намалени брой системни зависимости (от асоциация роли на сървър за обмен или без значение обикновен архитектура за съхранение без прекомерно число критични компоненти). Прости правила и формулиПредставен от Б. тази статия позволява изчисли влияние върху стойността наличност от разполагането допълнителен копия бази данни или от комбинация роли на сървър за обмен. T. просто може да бъде изчисли въздействие Точки на повреда. Реалния живот рядко подходящ за Б. прост основен сценарии, и нуждамного по-сложен изчисления, Придобивам разумен оценки Ниво на наличност реални системи; тя може да бъде улеснена ипросто мярка Ниво на наличност статистически и проверка, дали отговаря на изискванията SLA.. Въпреки това, разбиране на факторите засягащ достъпността заедно от сложност техническо решение трябва да помогне конструкция решение правилно I. постигане значително увеличение често срещани ниво на наличност Услуги дори за най-взискателните бизнес изисквания.

Наскоро аз все повече се засилвам дълго време в главата си и по-скоро еретична мисъл: класически индикатор за наличност е неподходящ за измерване и оценка на наличността на ИТ услуги в реалния свят. И в някои случаи може лесно да се отказва. Тези случаи се отнасят предимно за измерване на наличността на тип "" (всъщност е за неговата достъпност на бизнес процесите). Ще се опитам да оправдая и ще се радвам да чуя възражения.

Предполагам, че всички читатели на порталната формула познат:

Наличност \u003d (AST - DT) / AST,

където AST. - постоянно време на предоставяне на услуги, Dt. - размерът на престой за периода.

И вероятно познати трудности за използването му:

Първата сложност е свързана с дискусията на индикатора. Наличността се определя като 99.9%. Изглежда не е зле. Но 0.1% годишно е почти 9 часа. И един месец е почти 45 минути. И седмица - малко повече от 10 минути. И така, какво 99.9% означаваше клиентът? И доставчик на услуги?

Въпреки това следващият нюанс е много по-съществен: индикаторът е доста неточен, отразява отрицателно въздействие върху бизнеса. Ами ако всичко е без малко 9 часа годишно? Или услугата стана недостъпна за потребителите за две минути, но 15 пъти в един ден? Как това ще бъде изразено в проценти? .. следователно, например ITIL въвежда индикатори като MTRS, MTBF, MTBSI.

Но предлагам да се върна в началото на координатите и да зададете въпроса, защо обикновено въвеждаме наличността? Защо бизнесът прави изисквания за наличието на услуги? Защо доставчикът на услуги трябва да осигури висока наличност и да докладва за действителните си стойности? Отговорът е прост: Бизнесът носи загубата поради престой на ИТ услугите. Така че, идеалният за бизнес е индикатор за наличността, вероятно ще бъде метрична "загуба, дължаща се на престой IT услуги"?

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

• по-прозрачно излъчват наличието на бизнес процеси към ИТ инфраструктурата;
• по-разумно вземат решения по мерки, насочени към подобряване на толерантността към надеждността и грешката на ИТ системите;
• по-разумно оценява успеха на мерките за резултатите от тяхното прилагане.

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

Каква е загубата на бизнес в зависимост от времето на престой?

1. Колкото по-малък е през отчетния период, услугата е в режим на време, толкова по-голяма е загубата. Въвеждаме индикатор за "Общо престой".
2. Колкото по-дълго е една проста, толкова повече загуба. Често загубите не са постоянни навреме от величината и зависят от продължителността на прекъсването на експоненциално. За първи път щетите се състоят от несъвършени сделки, загуба на производителността на персонала и разходите за възстановяване, но от определен момент дългосрочен прост бизнес с глоби, санкции, увреждане на репутацията и т.н. Въвеждаме индикатора "максимално еднократно просто".
3. Редица бизнес процеси, напротив, са "чувствителни", а не за единични разходи, но до чести прекъсвания. Това е особено важен фактор за процесите, в рамките на който възникват дългосрочни изчисления, което в случай на прекъсване е необходимо да се рестартира. Така тя трябва да бъде предоставена като по-малко прекъсвания за периода. Въвеждаме индикатор "Брой нарушения".

Алтернативен (или допълнителен) метрик, отразяващ същия аспект, но с акцент върху периода на спокойни потребители, може да има индикатор "Минимална (или средна) продължителност на работата без нарушения."

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

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

От представените показатели можете лесно да отидете на известния MTRS, MTBF, MTBSI и, разбира се, класическия индикатор за наличност. Но по мое мнение предложеният комплект ще каже, че клиентът и доставчикът на услуги донякъде повече за бизнес влиянието на неговите нарушения. Или не?

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

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

Грубо казано, ако деактивирате интернет у дома, след това в крайна сметка ви плуни и отидете на разходка, в филм или Zabak, в най-добрия случай, надявайки се за преизчисляване.

Ако имате връзка в офиса, имате спирки на продажбите (клиентите не могат да преминат и без да чакат отговор по пощата, да отидат на други доставчици), счетоводството не може да провежда плащания (тук вече следвате партньорите си) и Ако, кажете, Бюрото на търговеца, количеството щети може да достигне хиляди долари (няма да можете да купувате или продавате акции във времето).

Може да има лирично отстъпление на резервациите на канала и т.н., но имаме пример пред очите ни - изграждането на Московския градски комплекс, в който преди няколко години неочакван начин и основен и резервен канал се оказа от един доставчик. И неприятностите, както знаете, не идва сам. В резултат на това два пъти за 7-8 часа (по време на работното време) се оказа без връзката на компанията от рейтинга на Fortune 500.
Ето защо, специално педантични правни услуги на фирми, чиято дейност е особено чувствителна към качеството на комуникацията, се опитват да изчислят размера на увреждането на дружеството не само на цената на неупертите услуги, но и в резултат на ползата от клиента в резултат на това на престой.

Точки

Ето някои показатели, в определен състав в документите на оператора:

ASR (съотношение на пристъпа на отговор) - параметър, определящ качеството на телефонната връзка в дадена посока. ASR се изчислява като процентно съотношение на броя в резултат на повиквания за телефонни връзки до общия брой предизвикателства в посочената посока.
PDD (забавяне след набиране) - параметърът, определящ периода (в секунди), който е преминал от повикването, докато телефонната връзка е зададена.
Коефициент за наличност на услуги - съотношението на прекъсването на времето в предоставянето на услуги от общото време, когато се предоставя услугата.

Коефициентна загуба на информационни пакети - съотношението на правилно получени пакети данни към общия брой пакети, които са били прехвърлени върху мрежата за определен период от време.
Временни закъснения при предаване на информационни пакети - интервал от време, необходим за предаване на информация между две мрежови устройства.
Отчетност на информационния трансфер - съотношението на броя на погрешно предадени пакети данни към общия брой предавани пакети данни.
Периоди на работа, времето на сигналите на абонатите и времето за възстановяване на услугите.
С други думи, наличието на услуги 99,99% показва, че операторът гарантира не повече от 4,3 минути съобщение на месец, 99,9% - че услугата не може да бъде 43.2 минути и 99% - че почивката може да продължи повече от 7 часа . На някои практикуващи се отличава наличността на мрежата и се приема по-малка стойност на параметъра - няма време. Различни видове услуги (трафик) също осигуряват различни стойности на показателите. Например, скоростта на закъснение е най-важна за гласа - тя трябва да бъде минимална. И скоростта за нея е необходима ниска, плюс някои от опаковките могат да загубят без загуба на качество (около 1% в зависимост от кодека). За да прехвърлите данни на първо място, скоростта излиза, а загубите на пакети трябва да се стремят към нула.

Световни стандарти

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

Забавяне на предаването на сигнала (латентност, MS)

	SprintNet.		Verizon.		Кабелна и безжична връзка.		NTT.
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	18.9	45	15.178	30	17.6	35.0	24.00	35
САЩ	36.91	55	42.851	45	45.9	65.0	45.83	60
Азия	83.78	105	100.640	125	48.3	90.0	47.34	95
Европа Азия	207.63	270	-	-	174.1	310.0	260.23	300
Европа-САЩ	74.53	95	78.784	90	78.7	90.0	71.57	90

Загуба на пакети (загуба на пакети,%)

	SprintNet.		Verizon.		Кабелна и безжична връзка.		NTT.
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	0	0.3%	0.025%	0.5%	0	0.2%	0	0.3%
САЩ	0.01%	0.3%	0.019%	0.5%	0.1%	0.2%	0	0.3%
Азия	0	0.3%	0.004%	1%	0	0.2%	0	0.3%
Европа Азия	0	0.3%	-	-	0	0.2%	0	0.3%
Европа-САЩ	0	0.3%	0	0.5%	0.1%	0.2%	0	0.3%

Трептене (изменение на закъснението, трептене, г-жа)

	SprintNet.		Verizon.		Кабелна и безжична връзка.		NTT.
	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт	Факт	Стандарт
Европа	0.0017	2	0.026	1	-	-	0	0.5
САЩ	0.0007	2	0.058	1	-	-	0	0.5
Азия	0.0201	2	-	-	-	-	0	0.5
Европа Азия	0.0001	2	-	-	-	-	0	0.5
Европа-САЩ	0.0001	2	-	-	-	-	0	0.5

Размерът на компенсацията зависи от месечните плащания на клиента и варира от доставчика на доставчика. В случая, когато индикаторът за наличност на мрежата надвишава прага, посочен в SLA, Verizon компенсира абоната на ежедневното плащане за всеки час от липсата на услугата. Ако в която и да е месец SLA не е изпълнена в индикатора за забавяне на предаването на сигнала, тогава компенсацията разчита в размер на дневните абонаментни такси.

Sprint е подходящ по-строго и ако SLA не се спазва (поне по отношение на), клиентът се връща в абонаментната такса за целия месец, в който е записан проблемът.

В случай на липсата на услугата NTT, операторът установява за себе си рамка за идентифициране и решаване на проблем за 15 минути - след което клиентът се появява от 1/30 до 7/30 от месечно плащане. Ако SLA не съответства на скоростта на забавяне на сигнала, клиентът може да разчита на дневните плащания на еднократно.

Нашите реалности

В руския бизнес за предпочитане е да SLA предимно международни марки. В същото време, за митрополитните клиенти, самата фраза също се познава и дори средните компании понякога се интересуват от този документ. Тук бих искал да отбележа, че споразумението за ниво на обслужване не заменя и не анулира позиционните точки на оператора в споразумението за предоставяне на услуги, както и нормите, установени от законодателството и актовете на субтитрите (например FZ "относно комуникациите" \\ t , Заповед № 92 "при одобрение на нормите върху електрическите параметри на основните цифрови канали и пътеки на основните и вътрешни първични мрежи на руския WCC и др.), Които ние следваме.

На практика, Гарс Телеком, в случай на "фасапи", спорове се уреждат по реда за обработка на билети и време за възстановяване на услуги. Производството, което доведе до неизползваемостта на услугата, трябва да бъдат елиминирани от 4 до 72 часа (в зависимост от причината). В случай на превишаване на посочените параметри, всеки допълнителен час на празен ход компенсира за абоната и когато се достигне праговият оператор, процентът на компенсация се увеличава.

От интересни случаи можете да си спомните магазина на музикални инструменти, които ни обвиняват (оператор) в падането на продажбите на пиано (за известно време телефонът не работи). Тук отново може да се сравни с усъвършенстван клиент-ориентиран на запад, но е по-добре да се обърне към руския пустош, където не е така, че SLA като цяло не съществува концепция за "възстановяване на услуги", не съществува. В най-добрия случай времето за реакция е 48 часа. Примерите дори не трябва да отидат далеч - на 15 км от Санкт Петербург - и местният оператор ще се дължи на всяка отговорност. Би било грозно да се говори за всички регионални оператори, но за съжаление това е по-скоро правило от изключение.

Какви заключения трябва да бъдат направени от тези истории

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