[ CoyoteKG @ 17.03.2018. 11:01 ] @
Čitam malo ovaj AWS i pominje se RAID, i da je kao vrlo zastupljen na ispitu.

Ajd, kapiram šta koji RAID radi, ali sam do sad onako laički mislio recimo kod RAID 0, čija je svrha brzina, mislio sam da se ta brzina ostvaruje jer se u jednom momentu podaci upisuju ili čitaju sa dva uređaja.
Recimo kod običinih HDD, dve glave će upisati i pročitati, i samim tim je brže.

Pa ako je to tačno, kako onda na EBS recimo ili bilo kom drugom Cloud-u, ukoliko napravim 4 particije po 10GB i spakujem ih u RAID 0 zar u stvari u pozadini neće raditi samo "jedan" uređaj? OK, kapiram da EBS nije samo jedan uređaj, ali da li ako napravim 4 EBS Volume, će biti kreirani na 4 fizički različita uređaja?
Ili ajd ovako, ako u VMware imam samo recimo jedan disk, i od njega napravim 4 VHD, i spakujem ih u raid 0, ima li smisla da će to raditi brže?

Isto i kod RAID 1. Ima li logike u Cloudu praviti RAID 1? Kapiram da je briga samog provajdera da imaju svoj hardverski raid i brinu o tome, zašto bi neko u Cloud-u pravio Raid 1? Pogotovo ako oba virtualna diska budu na istom uređaju.
[ bachi @ 17.03.2018. 11:06 ] @
Pa ako su virtualna diska na istom fizičkom disku, onda nema smisla, čak je i kontraproduktivno.

Ali ako nisu, onda ima.

Datacentri, odnosno "cloud" po defaultu ima neku vrstu redudantnosti, da li je to raid 1, ili raid 6 ili raid 10, tako da je moguće da je to neka marketingška žvaka,
[ since1986BC @ 17.03.2018. 13:23 ] @
Laik sam ali me interesuje ova tema.

U Cloudu RAID imas smisla samo ukoliko to zahteva arhitektura aplikacije?

Amazon RAID je (iskljucivo) na softverskom nivou?
Citat:
With Amazon EBS, you can use any of the standard RAID configurations that you can use with a traditional bare metal server, as long as that particular RAID configuration is supported by the operating system for your instance. This is because all RAID is accomplished at the software level. For greater I/O performance than you can achieve with a single volume, RAID 0 can stripe multiple volumes together; for on-instance redundancy, RAID 1 can mirror two volumes together.

https://docs.aws.amazon.com/AW...est/UserGuide/raid-config.html
[ CoyoteKG @ 17.03.2018. 14:08 ] @
Ne kapiram bas, sta u ovom slucaju je arhitektura aplikacije? I kako na nju raid moze da utice?
[ Aleksandar Đokić @ 17.03.2018. 14:08 ] @
Citat:
da li ako napravim 4 EBS Volume, će biti kreirani na 4 fizički različita uređaja?


Zavisi, moze i ne mora da bude.

EBS storage nije klasican storage... kako tacno radi cenim da bi mnogi voleli da znaju, uklucujuci mene :).
[ since1986BC @ 17.03.2018. 14:36 ] @
@CoyoteKG
Mislio sam na recimo web sajt/servis koji hostujes i njegovu arhitekturu (kako je isprogramiran da radi).

Laicki govoreci - npr sajt Oglasi:
-I deo odvojis za upload/hosting slika (kao CDN)
-II deo je za samu aplikaciju i procese
-III su baze/tabele
itd

@Aleksandar, mozda i ima objasnjeno za EBS ali se nisam interesovao.
YouTube ume da bude odlican izvor.
https://www.youtube.com/results?search_query=how+amazon+ebs+works
Ne verujem da ce ti reci u detalje kako se stite od napada i koje cake primenjuju - ono sto moze biti interesanto hakerima.
[ CoyoteKG @ 17.03.2018. 16:25 ] @
since, i dalje to ne mogu da povezem sa RAID :)
[ Aleksandar Đokić @ 17.03.2018. 20:32 ] @
Nema, to je sve sa korisnicke strane. Bilo malo nesto ranije na reddit-u i quora-i, ali nista konkretno.

Najvise info-a su dali kada im je bio davno downtime, pa se pravdali zbog cega i kako.

Citat:
t is helpful to understand the EBS architecture so that we can better explain the event. EBS is a distributed, replicated block data store that is optimized for consistency and low latency read and write access from EC2 instances. There are two main components of the EBS service: (i) a set of EBS clusters (each of which runs entirely inside of an Availability Zone) that store user data and serve requests to EC2 instances; and (ii) a set of control plane services that are used to coordinate user requests and propagate them to the EBS clusters running in each of the Availability Zones in the Region.

An EBS cluster is comprised of a set of EBS nodes. These nodes store replicas of EBS volume data and serve read and write requests to EC2 instances. EBS volume data is replicated to multiple EBS nodes for durability and availability. Each EBS node employs a peer-to-peer based, fast failover strategy that aggressively provisions new replicas if one of the copies ever gets out of sync or becomes unavailable. The nodes in an EBS cluster are connected to each other via two networks. The primary network is a high bandwidth network used in normal operation for all necessary communication with other EBS nodes, with EC2 instances, and with the EBS control plane services. The secondary network, the replication network, is a lower capacity network used as a back-up network to allow EBS nodes to reliably communicate with other nodes in the EBS cluster and provide overflow capacity for data replication. This network is not designed to handle all traffic from the primary network but rather provide highly-reliable connectivity between EBS nodes inside of an EBS cluster.

When a node loses connectivity to a node to which it is replicating data to, it assumes the other node failed. To preserve durability, it must find a new node to which it can replicate its data (this is called re-mirroring). As part of the re-mirroring process, the EBS node searches its EBS cluster for another node with enough available server space, establishes connectivity with the server, and propagates the volume data. In a normally functioning cluster, finding a location for the new replica occurs in milliseconds. While data is being re-mirrored, all nodes that have copies of the data hold onto the data until they can confirm that another node has taken ownership of their portion. This provides an additional level of protection against customer data loss. Also, when data on a customer’s volume is being re-mirrored, access to that data is blocked until the system has identified a new primary (or writable) replica. This is required for consistency of EBS volume data under all potential failure modes. From the perspective of an EC2 instance trying to do I/O on a volume while this is happening, the volume will appear “stuck”.

In addition to the EBS clusters, there is a set of control plane services that accepts user requests and propagates them to the appropriate EBS cluster. There is one set of EBS control plane services per EC2 Region, but the control plane itself is highly distributed across the Availability Zones to provide availability and fault tolerance. These control plane services also act as the authority to the EBS clusters when they elect primary replicas for each volume in the cluster (for consistency, there must only be a single primary replica for each volume at any time). While there are a few different services that comprise the control plane, we will refer to them collectively as the “EBS control plane” in this document.

https://aws.amazon.com/message/65648/


I dalje ono sto ja znam je da je EBS NAS storage, koji kace preko mreze na Xen 0domain gde se vrte EC2 instance. Ali mislim da nije klasican Xen, vec neka njihova verzija, plus ni Linux nije klasican vec takodje njihova neka filozofija (nesto slicno Amazon Linuxu).
[ Zlatni_bg @ 18.03.2018. 07:08 ] @
Gde si nasao preko AWS panela opciju za stavljanje EBSa u RAID?
[ nkrgovic @ 18.03.2018. 08:20 ] @
Da li si siguran da je RAID u pitanju? A ne neki JBOD... ?

Ja sam vise puta radio vgextend/lvextend/xfsresize sa AWS-u, to ima smisla. Dodas novi EBS, spojis ga sa starim u postoji vloume group, extendujes logical volume i grow-ujes file system. Skroz normalno ako ti za EC2 instancu treba da povecas prostor na disku. RAID, ne znam cemu bi sluzio. EC2 je navodno safe (tripple mirrored, valjda), performanse dobijas placanjem za provisioned IOPS.
[ CoyoteKG @ 18.03.2018. 11:40 ] @
Nema u AWS panelu, nego u OS.
Lekcija na koju sam naisao kod ecloud.guru

Creating a Windows EC2 Instance & RAID Group
Section 5, Lecture 37

Gda pominje da je često na pitanjima za sertifikat tipa, kako napraviti snapshot EC2 instance koja ima EBS u RAID. 3 načina na koji može da se uradi, jedan je stopiranje mašine. Za razliku od toga kada nema RAID, da može snapshot da se uradi bez problema dok je pokrenuta mašina.

Cela ova lekcija me buni, jer mi nema smisla da u Cloud koristi neko RAID 1, jer kao što Nikola kaže već je tripple mirrored, a opet RAID 0 mi nema smisla ako nema garancije da će svi EBS diskovi biti na različitim fizičkim uređajima.

No... može da se testira, a testiraću jednom, bencmarkovacu na jednom I/O, i posle ću napraviti raid od nekoliko diskova pa opet.
EBS verovatno funkcioniše drugacije pa verovatno da ima razlike
[ nkrgovic @ 18.03.2018. 14:11 ] @
Nije samo to ono sto mene buni. Ti na EBS imas provisioned IOPS. Ako ti trebaju performanse, mozes da uzmes do 32,000 IOPS-a. Ja stvarno ne mogu da zamislim primenu kojoj treba mnogo vise od toga, a da pri tome trpi unpredictable latency. Imam ideje gde 100K ili vise IOPS-a legne kao budali samar, naravo - ali nekako nista od toga ne mogu da zamislim da je load za cloud i gde nemas fixni predvidljiv I/O latency. Sve ostalo je ili troughput problem (sto se bolje reseava distribuiranim sistemom, a ne RAID-om), ili je problem kapaciteta (opet, 16TB je limit, a i to moze da se radi samo grow, ne mora RAID), ili je nesto sto trazi stabilan latency.

Da ne spominjem da, evo, sad zamisljam sistem koji ima npr. 100,000 IOPS-a... Moj produkcioni SSD GlusterFS cluster to ima, ali to trazi i brdo CPU-a, i solidno RAM-a, i jako performantnu mrezu za array rebuild. Kroz sta se kaci i na koju instancu se kaci 100K IOPS-a kao RAID iSCSI drajvova i koliko CPU-a ima ta instanca da joj ostane da nesto i radi..... ? Kad ti ispadne jedan disk koliko ti traje rebuild takvog softverskog RAID-a?
[ Aleksandar Đokić @ 18.03.2018. 14:19 ] @
To su neki cirkuzanti, ocigledno.
[ Zlatni_bg @ 19.03.2018. 18:42 ] @
Pa i poenta EBS-a je ta "elasticnost" o kojoj smo pricali u drugoj temi, kada ti zafali IOPSa, krene da botlnekuje, imas burst "poene" koji krenu da se trose i ubrza ti se EBS. Ali po mom misljenju, RAID radi povecanja brzine na serveru nema puno smisla. Mislim da industrijski/serverski SSD-ovi rade sasvim dovoljan posao, cepe se u RAID1 zbog mirroringa i resi se problem, eventualno RAID10, ali stvarno, stvarno ne znam koliko SSD voli RAID0 ili RAID10. Nikad nisam zeleo to da radim. Mnooogi kazu da se bas ubija TBW na njima tako...

Mozda je ovo nesto sto treba AWS support da se pita ipak?
[ Aleksandar Đokić @ 19.03.2018. 22:18 ] @
Cimnite Miroslava na pp :).
[ nkrgovic @ 20.03.2018. 08:58 ] @
Citat:
Zlatni_bg:
Pa i poenta EBS-a je ta "elasticnost" o kojoj smo pricali u drugoj temi, kada ti zafali IOPSa, krene da botlnekuje, imas burst "poene" koji krenu da se trose i ubrza ti se EBS. Ali po mom misljenju, RAID radi povecanja brzine na serveru nema puno smisla. Mislim da industrijski/serverski SSD-ovi rade sasvim dovoljan posao, cepe se u RAID1 zbog mirroringa i resi se problem, eventualno RAID10, ali stvarno, stvarno ne znam koliko SSD voli RAID0 ili RAID10. Nikad nisam zeleo to da radim. Mnooogi kazu da se bas ubija TBW na njima tako...

Ja imam GlusterFS storage od 3 masine sa po 6 1.9TB SSD-ova. Trebao mi kapacitet, trebali mi IOPS-i, ne vidim nista lose u resenju. Trosi malo diskove, ali ne previse - posebno kad uzmes o obzir da to i dalje zavisi od kolicine pisanja. U odnosu na to da platim te iste IOPS-e na AWS-u jos mi je i jevtino da uzmem lease + colo.
[ Zlatni_bg @ 21.03.2018. 02:35 ] @
Okej, ali Gluster je resenje koje ti implementiras sam na svojim serverima, a poenta AWSa je da uradi to za tebe :) Tj. tvoj nacin je DIY, zakupis hardver i podesis, dok AWS EBS treba da ti omoguci to sto si ti radio uz par klikova na dugme bez ikakvog pravog fizickog zakupa. Ako ne gresim :)

O isplativosti AWSa smo isto pricali, meni i Coyoteu objasnjeno da ne gledamo na taj nacin na AWS.
[ nkrgovic @ 21.03.2018. 13:12 ] @
Ma ja samo komentarisem deo kad si ti rekao da SSD u RAID-u nema smisla kao koncept - zelim ti reci da ima.

To da li je AWS isplativ nema veze sa ovime. Probam reci da SSD u RAID-u ima smisla van AWS-a. Znaci, nije problem RAID na SSD-u, problem je upotrebljivost RAID-a na AWS-u kao takvom. Cemu sluzi RAID ako imas cloud i nemas predictable latency, a mozes da dobijes dosta IOPS-a kao servis.
[ Zlatni_bg @ 23.03.2018. 01:40 ] @
Pa da, u sustini isto mislimo ali se nismo skapirali :) Ja sam samo dodao da SSDovi (nisam siguran za industrial/server-grade) ne vole preterano RAID0/10 na hardverskom nivou jer ume da im brljavi kontroler. Moguce da se i to vremenom ispravlja ili se ispravilo. Meni u serverskom okruzenju radi Kingston V300 vec 4+ godine i drzi se solidno iako nikako nije za tu namenu - al' jbg nisam imao nista drugo pri ruci tad. I istina, imam dosta citanja iz baze, nesto malo pisanja, to verovatno i drzi SSD zivim.

E sad, opet AWS treba da ti garantuje te IOPSe i da te spasi muke oko toga kako ces ti da resis problem. Ceo sistem funkcionise po principu bukvalno beogradskog sindikata - ti nam kazes sta ti treba mi ti javimo gde stize. Ne kapiram to celo poglavlje o RAIDu ako garantuju tripple mirroring (samim tim kazu da su oni odgovorni za redundantnost podataka) a brzinu sam biras. E sad, nisam siguran da nude preko 100k iopsa (npr samsung ssd koji imam, testirano ima oko 80k iopsa bez ikakvog raida), nisam imao potrebu za takvim stvarima jos. Neki SSDovi cak imaju firmware koji ogranicava iopse da bi ispostovali garantni rok u vremenskom smislu. Slagacu koji je ali neki torture testovi nisu bili validni na svim SSDovima zbog toga sto je brzina posle nekog vremena drasticno opadala. Ali ovde vec skrecemo sa teme o AWSu/cloudu.

Deluje mi ovo sve kao skup sport, i sam EBS je dovoljno skup, jos ako ce da se lupa RAID na bilo kom nivou... em AWS premium cene em duplo/cetvoroduplo/kolikogod. Staromodan sam i dalje izgleda :)