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

Од Википедија — слободната енциклопедија
Прејди на прегледникот Прејди на пребарувањето

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

Метрики[1][уреди | уреди извор]

Развиени се различни метрики за размерливост за паралелно пресметување, за да се процени ефективноста на даден акгоритам кој работи на платформи со различна големина, и да се спореди размерливоста на алгоритмите. Овие метрики претпоставуваа дека програмата работи сама, на сет од 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. Дуплирањето на процесирачката моќ го подобри забрзувањето само за околу една петтина. Ако се паралелизира целиот проблем, очекувано е да добиеме дупло забрзување. Затоа, додавање на повеќе хардвер не е секогаш оптимален пристап.

Хоризонтално и вертикално скалирање[2][уреди | уреди извор]

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

Вертикално скалирање[уреди | уреди извор]

Познато како 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/
    1. [1]
    2. [www.wikipedia.org/wiki/Scalabilit]