Размерливост на дистрибуиран систем

Најчесто, дистрибуирани системи мора да бидат размерливи. Сегашните и идните апликации вообичаено вклучуваат, веб засновани апликации, е-commerce, мултимедијални сервиси, учење од далечина, enterprise и мрежен менаџмент. Тие треба да се изводливи во голем опсег на величини, во услови на број на корисници и услуги, количина на зачувани манипулирани податоци, брзини на обработка, број на јазли, географска покриеност и големина на мрежа и уреди за складирање. Малите зголемувања може да бидат исто важни како и големите. Размерливоста значи не само работење туку работење, туку ефикасно работење со адекватен квалитет на услуги, во одреден опсег на конфигурации. Зголемениот капацитет треба да биде пропорционален со трошоците, и квалитетот на услуги треба да се задржи.

Метрики

Развиени се различни метрики за размерливост за паралелно пресметување, за да се процени делотворноста на даден акгоритам кој работи на платформи со различна големина, и да се спореди размерливоста на алгоритмите. Овие метрики претпоставуваа дека програмата работи сама, на сет од k обработувачи со одредена архитектура, и дека времето на извршување Т ги мери перформансите.

Познати се три поврзани видови метрики: метрики за забрзување, метрики за делотворност, и метрики за размерливост.

• Забрзување - S мери како се забрзува извршената работа со зголемувањето на обработувачите k, споредено со еден процесор, и има идеална линеарна вредност од S(k) = k.
• Делотворност – Е ја мера брзината на работа по процесор (тоа е, Е(k) = S(k) = k),.
• Размерливост – (k1; k2) од еден размер k1 до друг размер k2 е односот од ефикасноста за двата случаи, (k1; k2) = E(k2) = (k1).

Дизајн за размерливост

Често се препорачува системскиот дизајн да се фокусира на хардверска размерливост отколку на капацитет. Типично е поевтино да се додаде нов јазол на систем за да се постигне подобрени перформанси отколку да се учествува во подесување на перформансите за да се подобри капацитетот кој може да го поднесе секој јазол. Но, овој пристап може да има смалувачки ефекти. Под претпоставка: дека 70% од програма може де се забрза ако се паралелизира и да се избршува на повеќе обработувачи отколку еден. Ако α е парче од пресметка која е секвенцијална, и 1-α е парче кое може да се паралелизира, максималното забрзување може да се постигне со користење на Р обработувачи, според Амдаловиот Закон е:1/α+1-α/P. Ако ги замениме вредностите во претходниот пример, со четири обработувачи добиваме 1/(0.3+1-0.3/4)=2.105. Ако ја дуплираме пресметувачката моќ со осум обработувачи, добиваме 1/(0.3+1-0.3/8)=2.581. Дуплирањето на обработувачката моќ го подобри забрзувањето само за околу една петтина. Ако се паралелизира целиот проблем, очекувано е да добиеме дупло забрзување. Затоа, додавање на повеќе хардвер не е секогаш оптимален пристап.

Хоризонтално и вертикално скалирање

Методите за додавање на ресурси спаѓаат во две категории:

Вертикално скалирање

Познато како scaling up, значи додавање на хардвер на истата машина, најчесто обработувачи, меморија, па дури и виртуелизација . Одлики на ова скалирање се:

• Скапо
• Лесно за имплементација
• Една точка на пад (Single point of failure)

Хоризонтално скалирање

Познато како scaling out, значи додавање на машини на постоечките дистрибуирани системи. Со намалувањето на цените и порастот перформансите “евтини” компјутери може да се искористат за градење на дистрибуиран систем преку поврзување во кластери и постигнување на моќ еднаква на скапи опслужувачи. Одлики на ова скалирање се:

• Евтино
• Тешко за имплементирање
• Повеќе точки на пад, а со тоа и полесно се справуваат со кварови

Размерливост на Насочувачките протоколи

Денес најкористени протоколи се OSPF за “внатрешно” и BGP за “надворешно” насочување. Во однос на скалирање и други аспекти, овие се протоколи се подобрување во однос на претходната генерација протоколи, како RIP и EGP. Сепак, размерливоста е сè уште големо прашање кога имаме голема мрежа, кога насочувачкиот дизајн е “нечувствителен” на прашањата за скалирање, или имплементацијата на протоколот е неефикасна.

OSPF

OSPF е насочувачки протокол кој одржува состојба на линковите (link-state). Главната компонента на овој протокол е генерирање и одржување на базата за состојбата на линковите, која ја опишува насочувачката топологија на одредена турирачка област. Секој јазол во насочувачка област е одговорен за опис на својата локална топологија во Link State Advertisement –LSA. Секој генериран LSA се дистрибуира или поплавува (flooded) до сите насочувачи во областа. Секој насочувач добива LSA од сите други насочувачи, и формира база за состојбата на линковите која ја рефлектира насочувачката топологија на цела насочувачка област.

Главните проблеми поврзани со размерливоста се комплексноста на пресметките за одржувањето на состојбата на линковите, плус големината на базата за одржување на состојбата на линковите која придонесува на цената за насочувачки пресметки и потрошувачка на меморијата на насочувачот.

Целосно поврзана мрежа со N насочувачи ќе има О(N^2), LSA пакети во мрежата во случај на пад на еден линк. Link State протоколите обично користат Djikstra - Shortest Path First (SPF), алгоритмот за пресметка на насочувањето. Djikstra алгоритмот скалира до O(N^2), каде N е бројот на јазли. алгортмот може да се подобри до O(1*logN), каде 1 е бројот на линкови во мрежата и N е бројот на одредишта или насочувачи.

Следствено, протоколите со одржување на состојбата на линковите не скалираат добро во мрежна топологија со многу насочувачи и соседства во една област. Кога мрежната топологија е нестабилна, пресметката, трошоците за обработката и пропусниот опсег се зголемени, кое предизвикува потрошувачка на ресурси на насочувачот. Кога настанува flooding, ре-пресметка и други активности кои ги трошат обработувачкките ресурси, насочувачот не е во можност да алоцира обработувачкко време за да прати или обработи „HELLO“ пакети. Тогаш насочувачите во мрежата го губат соседството, кое ја зголемува нестабилноста. И како резултат, изолирана нестабилност ќе ескалира со пад на насочувачи низ целата мрежа.

BGP

BGP е меѓу-доменски насочувачки протокол кој дозволува размена на насочувачки или информации за достапност помеѓу Автономни Системи (АЅ). Функциоинално, BGP е составен од Надворешен BGP (E-BGP), и Внатрешен BGP (I-BGP). E-BGP се користи за размена на надворешни рути додека I-BGP типично се користи за дистрибуирање на надворешно научените рути во АЅ.

Главните трошоци на BGP се:

1. Потрошувачка на процесор во остварување на BGP сесија, селекција на рута, обработка на насочувачки информации и справување со насочувачки надградби.
2. Насочувачка меморија за инсталирање на рути и повеќе патишта поврзани со една рута.

Главниот проблем со скалирањето во BGP лежи во целосната поврзаност на I-BGP врските. Бидејќи не скалира за IGP да носи надворешно научени претставки, I-BGP ја презема оваа должност. За да се спречи насочувачки јамки, претставките научени преку I-BGP се забранува да се пренесат на друг I-BGP. Како резултат, потребен е целосен mesh од I-BGP сесии помеѓу насочувачи во АЅ. Во АЅ со N насочувачи, секој насочувач ќе треба да воспостави I-BGP сесии со N-1 насочувачи, и комплексноста на системот е во ред од O(N^2). Затоа, BGP слабо скалира кога бројот на насочувачи вмешани во I-BGP е голем.

Големиот број I-BGP сесии и рути трошат огромни ресурси од секој насочувач, поссебно при воспоставување на BGP сесии и при периоди со виори од рути.

Честите насочувачки надградби се друг потенцијален скалирачки проблем во големи мрежи. BGP користи инкрементални апдејти и праќа насочувачка информација за недостапни рути брзо за брза конвергенција. Ова е големо подобрување од ЕGP, во кој целата насочувачка табела се апдејтира во фиксен временски интервал. Сепак, кога мрежата е нестабилна од апдејти, посебно тие кои содржат насочувачки повлекувања, се праќаат веднаш, предизвикувајќи глобални BGP апдејти. Како резултат, мрежната нестабилност иницира апдејти низ целиот Интернет. Овој ефект е зголемен кога голем број рути се видливи на Интрнет, правејќи голем товар на насочувачите кои учествуваат во BGP.

Размерливост на доменски именски систем (DNS)

Причините за размерливоста на еден доменски именски систем DNS се помалку поради хиерархискиот дизајн на неговиот именски простор или доброто кеширање на А-Записи; отколу, кешибилноста на NS-Записите ефикасно го партиционира именскиот простор и избегнува преоптоварување на било кој именски опслужувач на Интернет. Капацитетот и размерливоста се потребни при менаџирање на DNS безбедносните додатоци (DNSSEC) и при D/DoS напади. Капацитетот е важен за одржување операции при напади, и е потребен за справување со зголемениот сообраќај при имплементацијата на DNSSEC. Размерливоста е многу важна, бидејќи имплементацијата на DNSSEC не само што ќе го зголеми сообраќајот, поголеми побарувања ќе паднат врз DNS платформата.

Размерливост на Gnutella

Кавгите околу тоа дали комплетно децентрализираниот дизајн како Gnutella може да поддржи голем број на јазли, се присутни уште од првиот ден на пуштање во употреба. Џастин Франкел, изумителот на Gnutella, тврдеше дека максимумот е 250-300 јазли. Gnutella тежи да генерира повеќе мрежен сообраќај од повеќето протоколи. Прва причина е бидејќи барање за пребарување треба да се прати до секој јазол кој способен да го исполни. Некои сметаа дека вакви претерани барања на достапниот пропусен опсег ќе ја колабира мрежата, и при голема големина Gnutella ќе стане неупотреблива. Можни против-аргументи се дека Gnutella мрежата веќе достигна голема големина без да колабира; дека лимитираниот век на Gnutella пораките не дозволува прекумерно користење на ресурси; и дека топологијата на Gnutella е исоморфичка со топологијата на Napster.

Постојат две важни предности на децентрилизираните протоколи:

• Првата е размерливоста,
• Втората е издржливоста на грешки.

Поврзано

How to achieve high scalability of Distributed Transactions within SOA?, http://www.quora.com/How-to-achieve-high-scalability-of-Distributed-Transactions-within-SOA

Наводи

1. Evaluating the Scalability of Distributed Systems, Prasad Jogalekar, Murray Woodside, Luminous Networks, San Jose, California.
2. http://www.wikipedia.org/wiki/Scalability.
3. http://www.wikipedia.org/wiki/Scalability.
4. http://www.faqs.org/rfcs/rfc2791.html
5. DNS Performance and the Effectiveness of Caching, Jaeyeon Jung, Emil Sit, Hari Balakrishnan, Member, IEEE, and Robert Morris, http://nms.csail.mit.edu/papers/dns-ton2002.pdf, http://communitydns.wordpress.com/2010/07/01/dns-platforms-a-study-in-capacity-and-scalability/.
6. Eman Elghoneimy, Scalability and Robustness of the Gnutella protocol, http://www.sfu.ca/~eelghone/