Што е кластер?

Кластерот се однесува на група компјутери (честопати се нарекуваат јазли) и други ресурси што се
поврзани преку хардвер, мрежи и софтвер за да се однесуваат како да се еден систем(тие се
поврзани преку LAN). Има многу причини што ова е привлечна работа да се направи, дури и за
помали претпријатија. Овие причини вклучуваат: голема достапност, балансирање на
оптоварување, паралелна обработка, управување со системи и приспособливост. Но, главната
работа што треба да се разбере сега за кластерирање е дека нејзината цел е да направи група
компјутери да се појават како да се тие еден, тотално интегриран систем кој е секогаш достапен и
секогаш работи брзо!

Компјутерските кластери се поделени во три класи:

Кластери за пресметка (Compute clusters)
Кластери за висока достапност на информации или сервиси (High
Availability -HA)
Кластери за балансирање на товарот (Load-balancing)

SIMD-Single Instruction Multiple Data

The same instruction is executed by multiple processors using different data streams.
SIMD computers exploit data-level parallelism by applying the same operations to multiple
items of data in parallel.
Each processor has its own data memory (hence the MD of SIMD), but there is a single
instruction memory and control processor, which fetches and dispatches instructions.

MIMD-Multiple Instruction Multiple Data

In contrast to SIMD processors, MIMD processors can execute different programs on
different processors.
 MIMD machines can be of either shared memory or distributed memory categories. These
classifications are based on how MIMD processors access memory.
 Shared memory machines may be of the bus-based, extended, or hierarchical type.
Distributed memory machines may have hypercube or mesh interconnection schemes

Network File System -NFS

►The Network File System (NFS) is a client/server application that let’s a computer user view
and optionally store and update files on a remote computer as though they were on the user's own
computer. The NFS protocol is one of several distributed file system standards for network-
attached storage (NAS).
►NFS was originally developed by Sun Microsystemsin the 1980'sand is now managed by the
Internet Engineering Task Force (IETF).
►Every machine can be a server and a client at the same time

NIS Overview
•Network Information Service (NIS) is a distributed database that allows you to maintain
consistent configuration files throughput your network.
•Formerly known as Yellow Pages or YP,NIS was developed in 1980 by SunMicrosystems.
•NIS is a part of the Network File System (NFS) software package that includes commands and
daemons for NFS, NIS, and other services.
•Although NFS and NIS are installed together as one package, each is independent and each is
configured and administered individually.
Beowulf е начин на градење на суперкомпјутер кој се состои од помали компјутери. Помалите
компјутери се поврзани помеѓу себе со LAN, најчесто Ethernet.

Кои се карактеристики на Beowulf?

- намалена зависност од производител – никаква зависност од хардвер/софтвер значи

имаме целосна контрола на системот и може да се скалира или модифицира. Не треба да
си привзан за одреден производител на хардвер.
- голем број на клустери извршуваат Linux OS, за неговата стабилност и брзина.
- нема ограниченсот на големината на Beowulf кластер.
- зашто сите Beowulfs се Linux, се што се пишува за еден Beowulf ќе се изведува точна на
останатите.

Мултикомпјутерска архитектура која може да се користи за паралелни пресметки. Системот се

состои од сервер јазол и еден или повеќе клиентски јазли поврзани преку Ethernet или друга
мрежа. Системот е изграден од хардверски компоненти кои извршуваат Unix-like OS, со
стандарден Ethenet адаптер и switches. Server јазол контролира цел кластер и дава датотеки на
клиентски јазли. Најчесто може да има повеќе од еден сервер јазол, и овој сервер јазол ги
контролира и конфигурира останатите јазли. Клиентските јазли не ги знаат IP адресите се додека
серверто не ги додели.

Разлика помеѓу Beowulf и Cluster of Workstation е дека Beowulf се однесува како единствена
машина наместо повеќе работни станици. Во повеќе случаеви, клиентските јазли немаат тастура
и монитор но само се пристапени преку надворешно најавување или преку терминал.

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

CENTOS
Quorum

Друг значен процес управуван од нивото комуникациското ниво на кластер е Quorum. Quorum е
минималниот број на кластер членови потребни да се изведе кластер операција. Кога се случува
паѓање на јазол, веднаш се бара реконфигурација на кластер. При процес на губење на член во
кластерот се менува број на членови во кластерот и останатите членови мора да направат
реконфигурација. Членовите во кластерот мора да донесат одлука за кластер јазолот со кој
услугите ќе бидат обновени. Врз основа на статусот на тековниот кластер, quorum мора да биде
постигнат низ кластер членовите и конечната одлука мора да биде прифтена. Се користи
дополнителен quorum диск кој е споеделен до сите членови на кластерот и се одвива
комуникација за heartbeat и се чуваат конфигурациски податоци. Кластер членовите може да
извршуваат комуникација преку овој диск.
Cluster stack e фраза која се користи за да се опиши кластерски софтвер кои се користи да
формира компјутерски кластер. Кластер стек е софтверски стек и може да вклучува сите
неопходен софтвер за нормални операции на кластер. Софтверот вклучен во кластер стек е
поделен според неговата примарна задача.

Cluster software stack мора да обебеди два знајчни карактеристики

1. Cluster communication – ова е лоцирано на ниско ниво од кластер stack со цел да биде
поблиску до транспортното ниво. Комуникацијата помеѓу членови на кластерот е
единствено возможна преку транспортното ниво. Зависи од изборот на софтвер за кластер
комуникацијата исто така за протоколот на транспортно ниво која комуникацијата го
подржува. (TCP/IP или UDP/IP)
2. Cluster resource management – топ ниво од cluster stack како резултат на конекцијата со
апликации од ОС. CRM започнува стопира и управува апликации во кластерот. Се заснова
на комуникациското ниво на кластерот да земе информации кои се барани за членови на
кластерот и нивниот статус и да земем акции кои се базирани на тоа. Софтверот за
комуникација на кластер и софтвер за управување на ресурси на кластер работат заедно
синхронизирано.

SUSE
Arbitrator – секоја страна извршува booth инстаца која е одговорна за комуницирање со друга
страна. Arbitrators се единствени машини кои извршуваат booth инстанци во специјален mode. Ако
сите booth инстанци комуницираат еден со друг, arbitrator може да направи по доверлива одлука
за земање или давање на тикети. Арбитраторите не може да држат тикети. Арбитраторот е битен
ако страната А не може да комуницира со страната Б, можни се два случаеви

- network failure помеѓу А и Б

- страната Б паѓа.

Ако страната C може сеуште да комуницира со страната Б, Б може да продолжи да комуницира.

АРХИТЕКТУРА
Membership and Messaging Layer (Corosync) – компоненттат дозволува доверливи пораки,
членови и quorum информации за кластерот. Ова е напревено преку Corosync cluster engine,
комуникациски систем.

Cluster Resource Manager (Placemaker) – resource manager кој е мозокот кој реагира на настани
кои се случуваат во кластер. Ги кординира сите акции. Настаните може да бидат
вклучување/исклучување на јазол во кластер, failure на ресурси, или распоредување на ресурси
како одржување.

Local Resource Manager – е лоциран помеѓу Placemaker layer и resource layer на секој јазол.
Имплементиран од даден daemon. Преку овој daemon, Placemaker може да започне, стопита или
мониторира ресурси.
Cluster Information Database – placemaker одржува БП за информации во кластер. XML
репрезентација на кластер конфигурација (кластер опции, јазли, реусрси, ограничувања, или врски
едни со други). CIB го прикажува тековниот статус во кластерот. Секоја кластер соджри CIB
реплика, која е синхронизирана низ целиот кластер. Daemon кој води грижа за читање или
запишување на конфигурации и статус во кластер.

Designated Coordinator (DC) – единствен ентитет во кластерот кој одлучува за проширување на

клатер ако треба да се изведе како што е fencing a node/ поместување на ресурси. Сите други јазли
земаат конфигурација и информација за алокација од тековен DC.

Policy engine – се извршува на секој јазол. Кога кластер пренесување е потрено, базирано на
тековната состоја и конфигурација, пресметува следна состојба на кластер. Одлучува која акција
треба да се распореди за да се постигне следен чекор.

Resource and Resource Agent – услугите треба да се високи достапни се наречени ресурси. RA се
скрипти кои започнуваа, стопитаат и мониторираат кластерски ресурси.
HADOOP Architecture
Master–slave architecture
Name Node (master):

It stores and manages names (file system name spaces) –The names of directories and
the names of files
Data Node (slave):

Manages and stores the data of the file

 All client interactions start with the Name Node

 Name Node can perform checks because it maintains an image of entire HDFS names
into memory – In memory FS Images

 Client creates data output stream and start writing data to this stream – FS data output
stream

 The file is broken into blocks and stored on Data Node

 Default block size is128MB

 The Name Node doesn’t store the data but the Name Node knows the amount of free disk
space at each Data Node. With that information, the Name Node can easily assign a Data Node
to store the block, and the streamer knows where to send the block.

 If the file is larger than one block, the streamer will again ask the Name Node for a new
block location.

 Data Node sends heartbeat (to inform the Name Node that is alive) and block report (info
of all the blocks that are maintain by the Data Node)

 Client directly interacts with Data Node for reading/writing blocks

 Name Node and Data Node can be installed on single machine to create a single node
cluster for learning
What is Map Reduce?
 Software framework and programming model used for processing huge amounts of data
with a parallel, distributed algorithm on a cluster.

 Used to handle a huge amount of data

 Two phases: Map function and Reduce function

 Distributed algorithm on a cluster

 Structured in (key, value) pairs

 Can handle a tremendous number of tasks including Counts,Search, Supervised and

Unsupervised learning and more.

 The "Map Reduce System" ("infrastructure" or "framework") orchestrates the processing

by marshalling the distributed servers, running the various tasks in parallel, managing all
communications and data transfers between the various parts of the system, and providing for
redundancy and fault tolerance.

 very useful for performing large-scale data analysis using multiple machines in the
cluster

MAP() function
The input data is first split into smaller blocks.
Each block is then assigned to a mapper for processing.
Takes a series of key/value pairs, processes each, and generates zero or more output
key/value pairs.
filtering and sorting

Reduce() function
Performs a summary operation
After all the mappers complete processing, the framework shuffles and sorts the results
before passing them on to the reducers.
A reducer cannot start while a mapper is still in progress.
All the map output values that have the same key are assigned to a single reducer, which
then aggregates the values for that key.
How Map-Reduce works?
 The whole process goes through four phases of execution:
 Splitting
 Mapping
 Shuffling
 Reducing
The complete execution process (execution of Map and Reduce tasks, both) is controlled
by two types of entities Job Tracker: Acts like a master(responsible for complete execution of
submitted job)
Multiple Task Trackers: Acts like slaves, each of them performing the job

Што се containers? Containers ја пакува целиот апликацски код и неговотите зависност и го

преместува на приватен или јавен cloud кој може да се симне и извршува секаде. Аплиакцијата ќе
се извршува секаде без ралика каде се извршува. Различни технологии за имплементирање се
користат како docker contrainers. Containers се тука да помогна да се справат со компатибилност
помеѓу различни верзии од компоненти во софтверски апликации и ги прават апликациите да се
извршуваат секаде.
Container stack е сличен со VM stack, прво се наоѓа физички или VM сервери следно се
наоѓа Host OS. Следно доаѓа дел од stack со кој се разликува container компонентата. За да може
да се работи со container потребно е да се инсталира docker технолија. Битна разлика помеѓу ВМ
стек и Container stack е дека VM вирулизираат на хардверско ниво додека container виртулизираат
ОС, така што може да има повеќе container кои се извршуваат на еден ОС. Сите container содржат
само потребните библиотеки и услуги за апликациии.

DOCKER – developer ќе напише код, ќе ја тестира апликација, тогаш developer ќе биде

спремен да ја спакува апликацијата, односно целиот конфигурациски код сите други компонети на
апликацијата во docker image. Docker image може да се споделува со сите и може да се прави
deploy. Потоа оваа слика може да се споделува на платформа наречена docker hub(исто како слика
на Google Drive). Со започнување на извршување на docker image тогаш се нарекува docker
container. инстанца на docker image е docker continers. Може да се прави скалирање на docker
containers според потреба. Затоа што може да се извршуваат повеќе docker containers нема
единствена точка на failure. Со инсталирање на docker engine може да се извршуваат повеќе
containers.
 Docker hub (Google driver-docker hub files-docker images, folder-repository ) прво се креира
docker hub, потоа се креира repository каде се става docker image.

Како containers се креирани и оджрувани, како container комуницраат помеѓу себе, како се прави
скалилрање на container ?
Container orchestration engine – потребна алатка со цел да може да се управува со голем број на
containers. Container orchestration обезбедува скабилност и кластерирање. Доколку не постои
кластерирање на сервер, во случај на откажување на сервер, апликацијата паѓа и тоа прествува
голем проблем. Исто така скалабиноста со docker engine не е едноставна потребно е container or.
engine.

Kubernetes е orchestrator за microservices apps кој се извршуваат на containers, додека

microservices app е апликација кој е напревена од помал број независни услуги. Kubernetes прави
orchestration за сите потребни делови да работат заеднп. Кога се започнува апликацијата, се се
пакува и се дава на кластер. Мастерот одредува на кој јазли ќе се изврши задача. Најдобар начин
да се даде пакуваната апликација на кластер е преку Kubernetes deployment. Се дефинира објект
наречен deployment, или се дефинира YAML датотека, кој е manifest што кажува на Kubernetes
како треба да изгледа нашата апликација. Кои images да се користат, кои порти, мрежи и колку
реплики да се дефинираат. Се дава оваа датотека на Kubertnestes на мастер, мастерот гледа во
датотека и deploy апликација на кластер.

Секој кластер има мастер сервер во кој има инсталирање и кофигурирано алатка наречена
container orchestration engine, соодветно има worker nodes. Woker nodes and master nodes го
формираат кластерот. Master nodes е одговорен за управување со worker nodes. следно што треба
да се направи е scheduling на овие worker nodes (deploy apps на одредени јазли). Пример да се
направи deploy на апликации на worker nodes каде имаат SSD driver. Сите наши барања ги
запишува во config files потоа се предава на container engine кои треба да ги изврши барањта.

Desired state and the Declarative Model

Kubernetess работи на декларативен модел, значи дека apiserver му даваме manifest files, што му
се кажува како треба да изгледа кластерот. Само му се кажува на мастерот, што сакаме он треба
да одреди што треба да направи за да излгеда како што сакаме. Манифест ја дефинира состојбата
на кластерот што сакаме да ја имаме (Desired state). Kubernetess мора да постигне нашата
посакувана состојба да биде иста тековната состојба на кластерот.

Pods – containers се извршуваат во pods. Pods не извршува нитшо, туку едноставно ги чува
containers, односно се гради мрежен стек, кернел именски простор и се извршува еден или повеќе
containers. Ако се извршуваат повеќе containers во еден под тие делат иста околина под. Ако треба
да имаме повеќе containers кои треба да споеделуваат меморија треба да се достапни под ист
под. Кога се прави скалирање се прави преку додавње или одземање на под. НЕ СЕ ПРАВИ СО
ДАВАЊЕ НА CONTAINERS ВО РАМКИ НА ИСТ ПОД.

Services – апликациите се прават од една или повеќе pods. Pods ако умре треба да се изгради нов
pods со нова IP адреса. Дури ако се прави скалирање се додаваат нови pods и тие доаѓаат со нови
IP адреси. Пример имаме апликација со storage како backend каде другите делови од
апликацијата ја користат да чуваат и врачаат податоци. Тоа се најчесто front-end pods кој ќе треба
да комуницра со back-end pods. Затоа се додава service object што е само Kubernetess object што се
дефинира во manifest датотека. Тој стои пред backend и обезбедува ставилни ИП адреси и ДНС
имиња за подс на backend. Има единствена ИП адреса и DNS имиња за load balancer кој ги
балансира барања на pods под негп.

Allocs – е резервирано множество на ресусрси на машина каде може да се извршуваат една или
повеќе задачи, ресурсите остануваат доделени без разлика дали се користат или не. Allocs може
да се користат за да се постават ресурсите за следни задачи, да се доделат ресурсите повторно
кога се стопира дадена задача и започнува одново, и да се соберат задачите од различни работи
на иста машина. Ресурсите на alloc се третирата на сличен начин како ресурс на машина, повеќе
задали може да се извршуваат со споделување на ресурси. Alloc ако мора да се реалоцира на
друга локација и со него мора да се прераспределат задачите. Alloc set е како задача, група на
alloc кој поврзуваат ресурси на повеќе машини. Од како се креира alloc set, една или повеќе задчи
може да се поднесат за извршување. Task ќе се однесува на alloc , job ќе се нарекува alloc set.

Priority, quota, admission control

Што се случува кога повеќе задачи треба да се извршат истовремено? – Се користи приоритет и
квота. Секоја работа има приоритет, некој мал позитивен број. Задача со повисок приоритет може
да добие ресурси со преземање на задача со помал приоритет. Borg дефинира приорите за
различни корисници, вклучувајќи (редослен на опаѓање на приоритет) : мониторирање,
продукција, batch и најдобра подршка.

Иако претходната задача ќе биде прераспределна на друго место во ќелијата, се случува каскаден
процес ако задачата со повисок приоритет исфрли задача со понизок приорите и така натаму. Па
затоа Borg спречува задача со поголем приоритет да исфрли задача со помал приоритет.

Приоритет дава релативна важност за задачите кои се извршуваат или чекаат да се извршат во
ќелија. Квота е користена да одреди која работата да се потврди за распоредерување. Квота е
изразено како вектор од квантите на ресурси со даден приоритет за даден временски период.
Квантитетот одредува максимален број на ресурси со кој работата на корисникот може да ги
побара во дадено време. Квота со повисок приоритет чинат повеќе него оние со понизок
приоритет. Приоритет на квоатата е лимитиран на достапните ресурси на ќелијата, така што
корисниците поднесуваат задача кој се поклопува со квоатат и се очекува да се извршува. Иако се
обесхрабуваат корисниците да купуваат квота кои ги задоволува потребите, голем број на
корисници купуваат повеќе од доволното , со цел да се надминат недостатоците кога
корисничката апликација расте. Алокацијата на квотата е справен надвор од Borg и се поврзува со
планирањето на физичкиот капацитет, чии резултатите се рефликтирани во цената и достапностат
на квоатата во различни датацентри.
Borg architecture – cell се состои од множество
на машини логички централизиран Borgmaster и
agent процес наречен Borglet кој се извршува на
една машина во ќелијата. Сите компоненти во
Borg се запишани во C++.

Borgmaster – секоја ќелија во Borgmaster се

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

Borgmaster е логички единствен процес но всушност е реплицран 5 пати. Секоја реплика одржува
копија од состојбата на ќелијата, исто така оваа состојба се запишува во високо достапне и
дистрибуиран начин на Paxos-based store. Единствен мастер по ќелија се однесува како Paxos
водач, се справува со промената на состојабата на ќелијата како поднесување на работа или
прекинување на задача на машината. Master е поврзан кога ќелијата започнува со работа и
секогаш поврзаниот мастер прекинува, и се стекнува со Chubby lock така што другите системи
може да го најдат.

Borglet - е локален Borg agent кој е присутен на секоја машина во ќелијата. Почнува и завршува
задача, рестартира ако падне, менаџира си локални ресури со манипулирање на ОС кернел, и ја
кажува состојабата на машината на Borgmaster и другите системи за мониторирање. Borgmaster
бара од секој Borglet да се види состојбата на машината и да се прати барање. Ова дава контрола
на Borgmaster за ратата на комунцикаја и избегнува потреба од експлцитен механизам за
контрола.

Поврзаниот мастер е одговорен за подготвување на порака да се прати до Borglet и да се ажурира

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

Ако Borglet не одговра на повеќе пораки се смета дека машината откажала и скеоја задача се
прераспределува на друга машина. Ако комуникацијата повторно е воспоставена, тогаш Borglet ги
убива другите задачи кои биле прераспределини за да се издвојат дупликати. borglet продолжува
со нормална извршување на задачи иако Borgmaster паѓа.

Omega - потребата за скалирање и потребата за брз одговор зза промена на барања се тешки со
тековната архитектура за распоредерување на monolithic cluster. Ограничувањата се ратата со кој
нови карактеристики може да се развиваат, намалување на ефикасноста и искористеноста и
лимитирање на растење на кластерот. За да се надмине ова се користи паралелизам, споделлена
состојба и оптимистричка истовремена контрола.
Azure Region е комплексен data centres лоциран во специфична географска локација.

Regions – е множество на datacenters кој се рамките на даден периметар и поврзани преку мрежа.
Оваа инфраструктура на Azure овозможува лесно да се развијат апликации.

Availability sets – висока достапност се постигнува преку редудатност. Редунданост значи дека
постои повеќе од еден ресур од истиот тип што може да земе контрола во случај кога имаме
примарен failure. Пример може да креираат повеќе виртуелни машини во еден availability sets што
стануваат високо достапни затоа што се поставени на посебни racks. Кога се прави ажурирање се
прави ажурирање на една ВМ и ова се постигнува преку fault domain/ update domain. Битно е да се
забележи дека се постигнува висока достапност во рамки на еден дата центар. Ако падне цел дата
центар значи дека достапноста на апликацијата ќе биде погодена. Па затоа се креираат availability
zones.

Availability zones е нов концепт во Azure, обезбедува висока достапност со поставување на ВМ

инстанци на различни дата центри во рамки на регион. Секој регион во Azure се состои од повеќе
дата центри. Во рамките на регионото ови дата центри формираат zones. Кога се поставува VMs во
availability zones се осигурува дека VMs се на различни дата центри и на различни racks и мрежи.
Затоа мора да се постават дата центрите во рамките на тој регион за да може да комуницраат
преку брза мрежа.

EC2 (Elastic Compute Cloud) е веб услуга кој обезбедува безбедност и капацитет за пресметување
во облак на developers. Интерфесј за едноставна веб услуга кој обезбедува целосна контрола на
конпјутерските ресурси и може да се извршува во околината на Amazon. Amazon EC2 го намалува
времето потреба да се започне нова инстанца на сервер, дозволувајќи брзо да се скалира
капацитетот, како што се менуваат потребите за пресметување. Amazon EC2 дозволува плаќање за
капацитет само што се користи од developers. Amazon EC2 обезбедува алатки да се развијат
еластини апликации и да се изолираат едни од други од сценарија на failure.

Карактеристики на Amazon EC2

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

- преконфигуриран template за иснатнцата, AMI потребите за ОС и дополнителн софтвер
- различни конфигурации на процесор, меморија, или мрежен капацитет за инстанците
познати како тип на инстанци
- инфромации за парови од клучеви за бездебности
- storage volumes за привремени податоци кои се стопираат или терминираат познати како
instances store volumes.
- persistent storage volumes за податоци користејќи Amazon EBS volumes.
- повеќе физички локазии за ресурсите како што се инстанци и Amazon EBS volumes низ
региони и AZs.
 - firewall кој овозможува да се специфицира протоколи, порти и изворни IP опсези кој
може да достигнат до нашите инстанци користејќи ги безбедносните групи
- Статички IPv4 адреси за динамчко облак пресметки познати како Elastic IP addresses.
- metadata/tags кој се креираат и доделуваат за Amazon EC2 ресурсите.
- Виртулени мрежи кои може да се креираат и логички изолираат од остатокот од AWS
облакот кој може да се поврзат за сопствената мрежа позната како virtual private clouds.

Amazon Elastic Blob Storage обезедува block-level storage volumes кои може да се прикач за
инстанца која се извршува. Може да се користи Amazon EBS како примарен storage device за
податоци кои бара чести и гранурални ажурирања. Пример, Amazon EBS е препорачан storage како
опција кога се извршува БП како инстанца.

Amazon S3 (Simple Storage Service) обезбедува пристап до доверливи и ефтини инфраструктури за

data storage. Дизајниран со цел да се овозможи да се чуваат и земаат било која големиа податоци
во било кое време во рамките на Amazon EC2 или било каде на веб. Пример, може да се користи
Amazon S3 за да се чуваат backup копиите на податоците и апликациите. Amazon EC2 користи
Amazon S3 за да ги зачува EBS snapshots и инстанци store-backed AMIs.

Амазон S3 Glacier
- Е безбеден, издржлив и има екстремно ниска цена на класите за складирање на
амазон S3 облак кои служат за архивирање на податоци и долгорочно чување на
дадени копии.
- Амазон Glacier се користи за архивски цели. Подобро е да се користи во ситуации
кога не е потребно често вадење на податоците, а најчесто се користи за чување
копии.
- Трошоците за складирање се многу помали во споредба со S3. Но, процесот за
преземање податоци е спор и трае неколку часа.
- Glacier е цврсто интегриран со S3 buckets кога сакаме да ги преместиме старите
податоци од S3 во Glacier за да ги намалиме трошоците.
- Во S3 е возможно да се постави управување на животниот циклус и автоматски да
се преместуваат датотеки кои се постари од даден број на денови Х од S3 во
Glacier.
- Слично на buckets во S3, во Glacier се креираат vaults (сводови) со цел да се чуваат
податоците. За да се ограничи пристапот, може да се доделат дозволи на vaults.
- Можеме да користиме Glacier за да ги архивираме нашите податоци директно.
Glacier исто така обезбедува и API интерфејс за Java и .NET.
- Важно е да се знае дека иако трошоците за складирање се помали во Glacier, сепак
има посебен, дополнителен трошок поврзан со преземањето на податоци.
Што е fabric controller? е дистрибуирана програма која управува хардвер и апликации цо
кластерот внатрешно користен од Azure. Главната задача е да се доделат соодветни ресурси на
апликацијата во рависност од бројот на инстанците и upgrade/fault domain кои се специфицирани
во апликацијата.

RDFE (RedDog Front End) е front end за сите услуги на Azure, и е одгвоорен да го избере кластерот
за дадена услуга. Постојат различни алгоритми со кои може да се избере кластерот, може да се
види дали корисникот го навел регионот, може да се прави deploy на услуга според поставеност
на другите услуги. Можеме да бидеме сигурни дека се поставени блиску една до друга според
мрежната топологија. Доколку не е наведен ниеден параметар треба да се види зафатеноста на
кластерот, односнно треба да се избере соодветниот кластер.

Azure прво обезбедувал класичен deployment model. Секој ресурс постоел неазивносо, немало
начин како да се групираат ресурсите. Морало мануелно да се прати кои ресурси се потребне за
градење на решение или апликација и треба да се памти начин за менаџирање на иститите. За да
се развие решние, требало да се креира секое решение независно преку портал или да се креира
скрипта така што се прави развивање на сите ресурси во точен редослед. За да се избрише дадено
решение потребно е да се избршат сите ресурси индивидуално.

Затоа се додава resource group кој е container за ресурси кои споделуваат заеднички животен
циклус. Карактеристики со кои се развива овој модел од претходниот

- може да се управуваат и мониторираат сите услуги за решение како група наместо да се

справуваме со секоја услуга индивидуално.
- контрола на пристап до сите реусрси во групата и автоматски овие полиси се применуваат
на новите ресурси кои се додаваат во resource групата.
- може да се додаваат tags до ресурсите кои се логички организирани сите ресурси
- може да се користи JavaScript Object Notation за да се дефинира инфраструктурата за
решението.

Role assignment – процес на доделување на дефиниција за улога за корисник, група , идентите

управуван од Azure во даден домен за да се дозволи пристап. Пристапот се дозволува
доделување на улога.