Бележки виртуална администратор клас бизнес критични приложения за виртуализация
Аз се случи да присъстват при десетината на презентации за бизнес приложения за виртуализация, и в повечето случаи е имал чувство за незавършеност. Като че ли бях пропуснал най-важната част. Виртуализация казват, че бизнес критични приложения във виртуални машини работят добре. Доставчиците ще представят желязо svli линия край хай оборудване за тези приложения.
Но това, което той наистина е клас "бизнес критични приложения" и как те otlichyutsya от останалите? Тъй като обикновено, когато говорим означава много за даденост, и в крайна сметка е объркващо, нека започнем от самото начало.
приложение
App - компютърна програма, предназначена за извършване на потребителски задачи. Това е различно от операционната система. предназначено да бъде слой между хардуера и приложенията. И системните програми. сервиране особен проблем за функционирането на целия комплекс (например дефрагментиране).
И така, критични за бизнеса приложения? За тази цел е необходимо да се справят с други думи.
Бизнес - дейности, насочени към печалба, просто казано. Т.е. бизнес приложения - това е приложение, използвани в оперативната дейност на предприятието, както и за функционирането на които зависи от печалбата.
Но тук отново въпроса - почти всяко приложение, с изключение, може би, Solitaire "Клондайк" се използва и може да се използва с цел печалба. Същото може да се използва Skype за комуникация с доставчици и клиенти.
Каква е разликата между прости бизнес приложения и критични за бизнеса приложения?
Бизнес критична
Бизнес-критичен заявление се счита, недостъпността на които води до осезаеми последици за бизнеса, т.е. печалбата на дружеството. До пълното спиране дейност. Да, разбирам, че има много по-напреднала теория и с отлична терминология, но в този случай аз не си поставям цели, за да ги замени. Това е обяснението за техническите експерти, обикновено не се изправи пред ITIL и непрекъснатост на дейността.
Ние ще продължим. Всъщност се оказва, че има определен мащаб на въздействието на приложения за бизнеса на компанията, и то е по същество непрекъснато, така че къде е необходимо да се тегли чертата и на какво основание? И след това как да се защитят тези приложения?
РПУ, RTO, SLO, SLA
За да стартирате приложение (и / или данни), трябва да се определи две мерки като РПУ и RTO.
РПУ - Recovery Point Цел, точка цел възстановяване. Т.е. Грубо казано, количеството данни, могат да загубят в произшествието.
RTO - Време за възстановяване Цел, време за възстановяване Цел. Т.е. грубо казано, колко можете да застане при катастрофа.
Ние го представлява във формата на графика, с нула в точката на инцидента. хоризонтална скала на времето, вертикално пари. Съответно. възстановяването на точката ще бъде в отрицателна посока по отношение на времето и средната загуба на данни за N часа. време за възстановяване, по позитивен начин респ. означава определяне на времето, докато възобновяването на заявлението. Но това, което е там пари?
И ето какво. Колкото повече данни ще бъдат загубени, и колкото по-дълго прост - толкова повече пари на компанията губи. Но искам да подчертая - че тази графика не ИТ отдела. Това прави стопанската единица и IT приема за даденост, а като ръководство за действие.
Т.е. за интелигентен, преди да се говори за бизнес приложения и тяхната защита, първо трябва да се направи пълен опис на приложенията и данните, и да направи тяхната класификация. След това, в зависимост от приложението, за да се изгради един от друг и от базата данни. И излезе с печалба щастие на търговски, например, на директора и да избягате от цената на часа от загуба на данни и времето за престой часа за всяко приложение. Въпреки че няма цена - всичките приказки за бизнес приложения и тяхната защита са безсмислени, и са по същество един образован залог с пръст към небето.
Бих искал също така да се отбележи, че графикът може да бъде много по-различна за всяко приложение, в зависимост от приложението и дори индустрията. И не винаги ще бъде симетричен.
Добре, ние имаме този график, какво да правя?
И тук на диаграма наслагват крива разходите за защита от престоите и загуба на данни. Лесно е да се забележи, че има точки на пресичане на тези криви.
В тези точки, цената на защита в сравнение със загубите, а именно тези две магически точки са ориентир за нас. Всичко, което е по-близо до точката на неуспех, ще доведе до по-малка загуба на пари поради престой, но загубата на пари за отбрана ще бъде повече от цената на престой. Т.е. всичко между тези две точки, е икономически неизгодно.
От друга страна, той получава ръцете си върху икономическите аргументи за защита - архивиране, групиране и т.н. директно от ръцете на стопанските единици. "След като прекара 10 рубли на резервната система, ние се ограничи рискът от загуба на данни, 10-а в стойността на рублата на данните."
И тук има два нови трибуквени съкращения.
SLO - Service Level Цел, целевото равнище на обслужване. Т.е. за всяко приложение и клас данни ИТ с бизнес единица, тези две точки, които са RPO / RTO.
Споразумение за ниво на обслужване, споразумение за нивото на обслужване - SLA. В действителност това е просто един документ, описан SLO и незадължителните санкции за неговото нарушаване. Разбира се, наказанието е по избор за вътрешен документ и е абсолютно необходимо, ако SLA е външен доставчик на услуги.
На тази за днес, и в бъдеще ще говорим за въздействието на виртуализация на всички тези съкращения.
Е, вие също, така че не се опрости, а по-късно на "технически експерти" ще се изправят пред Business Continuity и идват да се закълне;)
Пресечната точка на тези криви - това е хитър, макар и чести. Защо е необходимо да се харчат пари X, да не загуби още един X? И това може да бъде по-добре да прекарат X / 2, и го приемам рискът от загуба 3X? На практика - определя бизнес цели въз основа на различни критерии (различни от пари, може да има, например, риск за репутацията, или съответствието) и в отговор, се казва, колко пари може да ги постигне. И ако съотношението разходи / ползи адекватно - тогава няма да има пари в проекта са дадени.
Lesh, знаете ли, текущото състояние на ИТ специалистите в разбирането дори на РПУ / RTO никога щастлив. Ето защо репликация и защо не можем просто да направите резервно.
Знаеш ли, защото аз наистина не пиша нищо, че не казва на всяка втора среща. Това е нов непознат свят за техничари, и може би това е малко по-опростен, почти на нивото на детските приказки за вас. Но ти и аз имаме различни целеви аудитории и различни цели. Моята цел - да обясни защо ние говорим за това, защо за изпълнение на задачата, избрано 8-контролер клас съхранение Hi-End, вместо 2-контролер клас Среден клас. Или обратното. Целта - да се показват на пръстите си, когато е щипки обувката.
Точно така-така! Как ангажирана избор на желязо / софтуер, не е имало един единствен друга причина, то "и нека на повече ядра, гигабайта, и про / предприятието версия"!