Malalim na pagsisid sa Amazon S3 (STG407)

Mga Tala ng Sesyon

Panimula

• Mga Istratehiya sa Antas ng Server para sa Paghawak ng mga Pagkabigo
• Nakatuon ang serye sa mas mababang antas ng mga detalye ng mga operasyong S3
• Pokus sa taong ito: pagdidisenyo para sa availability
• Diskarte
• Dalawang anggulo: antas ng system at mga view sa antas ng server
• View ng antas ng system sa arkitektura ng pagkabigo, pagkakapare-pareho ng read-after-write, pagpapatupad ng pagkabigo
• Pagtukoy sa Mga Tuntunin
• Availability: pagharap sa kabiguan
• Pagkabigo: mga bahagi na maaaring mabigo (mga drive, server, rack, mga gusali)
• Mga uri ng pagkabigo: permanenteng pagkawala o pansamantalang kawalan ng kakayahang magamit (power, networking, overload)
• Mga layunin sa disenyo: idinisenyo ang system ayon sa mga layunin (hal., 99.99% availability, 11 9s durability, read-after-write consistency)
• Mga Layunin sa Disenyo ng S3
• Idinisenyo para sa mataas na kakayahang magamit at tibay
• Read-after-write consistency ipinakilala sa 2020
• Bago ang 2020, katanggap-tanggap na paghawak ng kabiguan ay kasama ang paglabag sa mga garantiya sa pagkakapare-pareho

S3 Bago ang Consistency Launch: Paghawak ng mga Failures at ang Indexing Subsystem

Kahulugan ng Consistency

• Consistency: property na sinasalamin ng isang object GET ang pinakakamakailang PUT sa object na
• Indexing Subsystem
• May hawak na object metadata (pangalan, tag, oras ng paggawa)
• Na-access sa bawat kahilingan sa data plane (GET, PUT, LIST, HEAD, DELETE)
• Mas maraming kahilingan ang napupunta sa index kaysa sa storage subsystem
• Core ng indexing system: dedikadong storage para sa matibay na paghawak ng mga entry sa index na
• Quorum-Based Algorithm
• Ang data na nakaimbak sa mga replika gamit ang isang quorum-based na algorithm
• Pagpapatawad sa mga kabiguan
• Tumatakbo ang mga server sa magkahiwalay na Availability Zone (AZ) upang maiwasan ang ugnayan sa isang domain ng fault
• Ang pagkabigo ng anumang solong disk, server, rack, o zone ay nakakaapekto lamang sa isang maliit na subset ng data
• Quorum Implementation sa Index
• Kailangang magbasa at magsulat para maabot ang karamihan ng mga server
• Halimbawa: ang pagsulat ng halaga A ay nagtagumpay sa lahat ng mga node
• Pagsusulat ng halaga B: nabigo ang isang node, ngunit nagtagumpay ang B sa karamihan ng mga server (walang epekto sa pagkakaroon)
• Nagsisimula ang Reader ng pagbabasa: nabigo ang isang server, ngunit ang dalawa pang nagbabalik na halaga B
• Paglutas ng salungatan sa pamamagitan ng nauugnay na timestamp (B nanalo sa A)
• Nagtatagumpay ang pagbabasa at pagsusulat sa kabila ng mga pagkabigo ng server sa gitna ng mga kahilingan
• Available ang system dahil sa maraming node at allowance para sa pagkabigo

Quorum-Based Algorithms sa Distributed Systems

Pangkalahatang-ideya

• Tinitiyak ng mga algorithm na nakabatay sa korum ang pare-pareho at fault tolerance sa pamamagitan ng pag-aatas ng minimum na bilang ng mga node (quorum) upang magkasundo sa mga aksyon tulad ng pagbabasa o pagsusulat ng data.
• Pinipigilan ang pagkasira ng data kapag nabigo ang ilang mga node.

Mga Pangunahing Konsepto

Mga korum

• Tukuyin ang kabuuang bilang ng mga node (N), isulat ang quorum (W), at basahin ang quorum (R).
• Basahin ang operasyon:
• Ang isang read request ay napupunta sa isang set ng mga node; ang operasyon ay magtagumpay kung ang mga tugon mula sa mga R node ay natanggap.
• Isulat ang operasyon:
• Ang isang kahilingan sa pagsulat ay napupunta sa isang hanay ng mga node; gagawin ang pagsulat kung kumpirmahin ito ng mga W node.
• Consistency:
• Tinitiyak ng panuntunang R + W > N na ang anumang read ay makikita ang pinakabagong nakasulat na data, dahil ang read set at write set ay dapat mag-overlap ng kahit isang node.
• Fault Tolerance:
• Kung mabigo ang isang node, maaari pa ring bumuo ang system ng isang quorum (hal., ang isang 3-out-of-5 system ay nagpaparaya sa mga 2 failure).

Mga Halimbawa at Aplikasyon

Pagtitiklop ng Data

• Pagtitiyak na mananatiling pare-pareho ang lahat ng kopya ng data sa isang cluster (hal., sa mga database tulad ng Cassandra).
• Mutual Exclusion (Maekawa's Algorithm):
• Humihiling ng pahintulot ang mga node mula sa kanilang quorum upang ma-access ang isang nakabahaging mapagkukunan (kritikal na seksyon), na tinitiyak na isang node lang ang pumapasok sa isang pagkakataon.
• Pinagkasunduan (Paxos):
• Isang foundational protocol para sa mga distributed system na sumang-ayon sa isang halaga, mahalaga para sa halalan ng pinuno at pagkopya ng makina ng estado.

Mga Pangunahing Parameter (URW Modelo)

• N: Kabuuang bilang ng mga kopya ng data (mga node).
• W: Sumulat ng quorum (kailangan ang mga node para kumpirmahin ang pagsulat).
• R: Basahin ang korum (kailangan ang mga node para kumpirmahin ang isang nabasa).

S3 Quorum-Based System: Tinitiyak ang Mataas na Availability at Consistency

Mga Prinsipyo ng Korum sa S3- Mga Katugmang Sistema

• Gumagamit ng mga prinsipyo ng korum (karamihan ng mga node na sumasang-ayon) para sa mataas na kakayahang magamit at pagkakapare-pareho
• May kaugnayan sa mga clustered o edge na setup (hal., Amazon S3 sa Snowball Edge)

Paano Ito Gumagana sa S3-Like Systems

Ibinahagi ang Pinagkasunduan

• Ang mga monitor o tagapamahala ay bumubuo ng isang korum (karaniwan ay 3+) upang subaybayan ang kalusugan ng node
• Ipinaalam sa mga kliyente ang tungkol sa mga available na storage node
• Mga Pagpapatakbo ng Pagsusulat:
• Magtatagumpay lamang ang pagsulat kapag kinikilala ito ng mayorya (quorum) ng mga storage node
• Tinitiyak ang tibay at pagkakapare-pareho ng data sa buong cluster
• Read Operations:
• Tina-target ng Reads ang isang korum ng mga replika upang magarantiya ang up-to-date na data
• Fault Tolerance:
• Maaaring tiisin ang mga pagkabigo ng f node na may kabuuang 2f+1 na mga replika
• Maaaring mahalal ang mga bagong pinuno, at magpapatuloy ang mga operasyon hangga't nananatili ang isang korum

Mga Pangunahing Halimbawa

Amazon S3 sa Snowball Edge

• Gumagamit ang mga cluster ng Snowball Edge na device ng quorum para sa S3-compatible na storage
• Namamahala sa status ng device at availability ng data
• Ceph:
• Gumamit ng mga monitor at OSD (Object Storage Daemons) na may korum.
• Pinapanatili ang cluster state at availability ng data bilang isang S3-compatible na backend.
• Ang Object Storage Daemons (OSDs) ay ang mga pangunahing proseso ng pag-iimbak ng data sa isang distributed system tulad ng Ceph, na kumikilos bilang mga indibidwal na storage unit na namamahala sa mga lokal na disk (HDDs/SSDs) at humahawak ng replikasyon, pagbawi, at pamamahagi ng data para sa malaking halaga ng hindi nakaayos na data, na ginagawa itong pangunahing para sa scalable, resilient object storage.
• Mga Ibinahagi na Consensus Libraries:
• Ginagamit ng GitHub ang mga conditional operations (ETags) ng S3 para sa halalan ng pinuno at mga Pangunahing Function ng korum ng isang OSD:
• Imbakan ng Data: Nag-iimbak ng mga aktwal na bagay ng data sa isang lokal na filesystem (tulad ng XFS).
• Pamamahala ng Data: Pinamamahalaan ang pagtitiklop ng data (paggawa ng mga kopya) at pagbawi (pagbubuo muli ng nawalang data) sa buong cluster.
• Pagsubaybay sa Tibok ng Puso: Sinusuri ang ibang mga OSD para sa kalusugan, pag-uulat ng katayuan sa Ceph Monitor.
• Access sa Network: Nagbibigay ng access sa network sa nakaimbak na data para sa mga kliyente.

Core S3 kumpara sa Quorum-Based

Amazon S3 (Core)

• Nagbibigay ng malakas na read-after-write consistency natively sa buong pandaigdigang imprastraktura
• Walang tahasang pamamahala ng gumagamit ng mga korum
• S3 Batay sa Quorum (Clustered/Edge):
• Naglalapat ng mga konsepto ng korum sa loob ng mga cluster na pinamamahalaan ng user ng mga S3-compatible na device
• Tinitiyak ang internal consistency at availability sa loob ng cluster

S3's System Level Availability Design at Caching Layer

Sentral na Konsepto

• Maramihang node na iruruta at headroom para sa pagkabigo
• Isinaayos at sukat para makamit ang 99.99% mga layunin sa availability
• Read-After-Write Consistency Bago 2020
• Nakita ng mga mambabasa ang mga halagang isinulat ng mga manunulat dahil sa magkakapatong na mga pagbabasa at pagsusulat (parehong kinakailangang maabot ang karamihan ng mga server)
• Tanong: Bakit hindi pare-pareho ang S3 read-after-write bago ang 2020?
• Sagot: Caching layer
• Caching Layer
• Ang front end ng S3 ay mabigat na nag-cache ng mga bagay na madalas ma-access
• Hindi pare-parehong nabasa: ibinalik ang value B sa halip na C (huling value na isinulat)
• Ang pagbabasa at pagsusulat ay hindi nagsasapawan sa cache
• Ang cache ay may pangunahing pag-aari ng availability (maraming mga host ay maaaring makatanggap ng mga kahilingan, allowance para sa pagkabigo)
• Walang overlap sa pagbabasa at pagsusulat sa cache
• Katanggap-tanggap na paraan upang harapin ang kabiguan bago 2020 dahil sa mga layunin sa disenyo na hindi kasama ang pagkakapare-pareho
• Halimbawa ng Caching Layer:
• Walang laman ang mga node ng cache na may mga value B sa storage
• Nagbabasa ang mambabasa sa pamamagitan ng cache node, ibinalik ang halaga B at naninirahan sa cache
• Sumulat para sa C ay nag-o-overwrite ng bagay, nagpapatuloy sa mga replika (C C C)
• Ang mga value B at C ay naka-cache sa magkahiwalay na node (disenyo bago ang 2020)
• Basahin ang mga ruta sa dating cache node, ibinabalik ang halaga B (hindi pare-parehong nabasa)

Paglutas ng Overlap na Problema gamit ang Cache Coherency Protocol

Pinaka-Hinihiling na Feature: Consistency

• Consistency ang pinaka-hinihiling na feature bago 2020
• Layunin: lutasin ang overlap na problema sa caching layer ng
• Cache Coherency Protocol
• Kailangang maging mabilis, mahusay, at magagamit
• Panatilihin ang pag-aari ng maraming server na tumatanggap ng mga kahilingan habang pinapayagan ang ilan na mabigo
• Solusyon: replicated journal
• Replicated Journal
• Ibinahagi ang istraktura ng data kung saan ang mga node ay magkakadena
• Sumulat ng daloy sa mga node nang sunud-sunod
• Ang bawat node ay pasulong sa susunod na node
• Kapag sa pamamagitan ng journal, ang mga pagsusulat ay ipinapadala sa korum ng mga storage node
• Sinusubaybayan ng journal ang kamakailang kasaysayan at sumasang-ayon sa pag-order
• Halimbawa: Ang A ay nauuna sa B
• Ang sistemang nakabatay sa korum ay hindi maaaring mangatuwiran tungkol sa pag-order nang tama
• Gumagawa ang journal ng mahusay na tinukoy na pag-order para sa mga mutasyon ng
• Mga Numero ng Pagkakasunud-sunod at Mga Watermark
• Ang lahat ng pagsusulat ay nagtalaga ng sequence number (tumataas sa paglipas ng panahon)
• Halimbawa: A (sequence number 1), B (sequence number 2), C (sequence number 3)
• Ang mga storage node ay natututo ng sequence number kasama ng value
• Sequence number na nakaimbak sa cache kasama ang value
• Ang cache node ay maaaring magtanong kung may anumang mga pagsusulat na dumating pagkatapos ng isang naibigay na sequence number na
• Witness System
• Layunin: subaybayan ang mataas na marka ng tubig para sa mga pagsusulat sa index
• Hindi kailangang hawakan ng saksi ang aktwal na data, sequence number lang
• Maaaring mag-overestimate ang testigo sa huling sequence number (ligtas na sabihin sa tumatawag na sila ay lipas na)
• Magbabasa ang tumatawag mula sa storage at makakakuha ng tamang resulta kung sasabihing lipas na sila

Pagtiyak ng Failure Allowance at Consistency sa Dynamic Reconfiguration

Sistema ng Saksi

• In-memory data structure (array of integers) sa tabi ng journal
• Nagbibigay-daan sa mga node ng cache na magtanong kung may anumang pagsusulat na pumasok pagkatapos ng naka-cache na halaga
• Binagong read at write algorithm:
• Nagsusulat pumunta sa journal
• Binabasa ang pakikipag-usap sa saksi; kung maayos, bumalik mula sa cache; kung lipas na, pumunta sa storage
• Lost Failure Allowance
• Orihinal na arkitektura ng journal: kung nabigo ang isang node, ang pagsusulat ay hindi maaaring umunlad sa system
• Ang mga serbisyo ng korum ay nagsusulat nang sabay-sabay; Ang journal ay nagpapadala ng mga pagsusulat sa pamamagitan ng sunud-sunod
• Maaaring ihinto ng pagkabigo ng node sa journal ang buong sistema ng
• Dynamic Reconfiguration
• Ipinakilala upang ayusin ang isyu sa allowance sa pagkabigo
• Sinusubaybayan ng mga node sa journal ang availability ng bawat isa
• Patuloy na pag-ping sa isa't isa; mga mensaheng dumadaan sa system
• Ang mga node ay may up-to-date na view ng availability ng kapitbahay
• Kapag nakakaranas ng isyu, humihiling ang mga node sa isang quorum-based na configuration system na muling i-configure ang journal
• Nangyayari ang muling pagsasaayos sa loob ng millisecond ng isang node na nabigo
• Configuration system mismo ay quorum-based
• Result
• Cache na may allowance sa pagkabigo at magkakapatong na pagbabasa at pagsusulat
• S3 ay pareho na ngayong pare-pareho at lubos na magagamit
• Napanatili ang mataas na kakayahang magamit sa pamamagitan ng pare-parehong paglulunsad sa pamamagitan ng pagdidisenyo para dito ng
• System-Wide Availability Perspective
• Kailangan ng maraming server na mapagpipilian
• Kinakailangan lamang upang magtagumpay sa ilan
• Kakayahang muling i-configure ang system nang mabilis sa harap ng pagkabigo
• Ang mga algorithm na nakabatay sa korum ay palaging naroroon, kahit na sa mga system tulad ng journal

Pagharap sa Kabiguan sa Antas ng Pagpapatupad

Pag-unawa sa Kabiguan

• Tanong: Ano ang maaaring mabigo?
• Ang mga nauugnay na kabiguan ay mahalaga: mga kabiguan na nangyayari nang magkasama
• Ang mga nauugnay na pagkabigo ay mahalaga para sa pag-iisip tungkol sa availability
• Disenyo ng korum: OK para mabigo ang isang node, ngunit hindi kung ang lahat ng node ay nasa parehong AZ o rack

Mga Pisikal na Kabiguan

Mataas na antas ng pisikal na pagtingin sa S3

• Maramihang Availability Zone (AZ)
• Ang bawat AZ ay may maraming rack ng mga server
• Ang bawat server ay may maramihang mga hard drive
• Mga uri ng pisikal na pagkabigo:
• Mga indibidwal na pagkabigo: nasira ang motor ng hard drive, nababakas ang platter
• Mga kaugnay na pagkabigo:
• Pagkabigo ng server: lahat ng naka-attach na hard drive ay lilitaw na nabigo
• Rack failure: lahat ng drive sa rack fail (hal., bad switch)
• AZ pagkabigo: bumagsak ang buong AZ (hal., pagkawala ng kuryente)
• Mga Logical Failures
• Halimbawa: pag-deploy ng bagong software sa fleet
• I-deploy sa ilang node nang paisa-isa, unti-unting pataasin
• Ang hanay ng mga server na may bagong software ay bumubuo ng isang failure domain
• Kung may bug sa bagong software, maaaring mabigo ang lahat ng server na iyon nang magkasama
• Kailangan ng matalinong diskarte sa pag-deploy para ma-tolerate ang mga potensyal na pagkabigo

Pagdidisenyo sa Paligid ng Mga Kaugnay na Pagkabigo

Paglalantad ng Mga Workload sa Maramihang Mga Domain ng Pagkabigo

• Pagtitiklop ng mga bagay sa maraming lokasyon (hal., mga AZ) para sa tibay at availability
• Tinitiyak na mananatiling available ang data kahit na nabigo ang isang nauugnay na domain ng pagkabigo (hal., AZ, rack, server)

Pag-unawa sa Mga Uri ng Pagkabigo

Fail-stop failure

• huminto sa paggana ang server o component (hal., hinatak ang power cord)
• Madaling matukoy at magreact sa isang mapagparaya na system Fail-stop failure sa isang switch sa pagitan ng mga
• AZ:
• Patuloy na nagtagumpay ang ilang kahilingan (sa loob ng parehong AZ)
• Nagsisimulang mabigo ang iba pang mga kahilingan (pagdaraan sa nabigong switch)
• Nagreresulta sa fuzzy failure mode kung saan nagtagumpay ang ilang kahilingan at nabigo ang ilan

Pagdidisenyo sa Paligid ng Fuzzy Failure Mode

• Ang kalabisan ay susi: maraming switch sa pagitan ng mga AZ
• 3 AZ sa bawat rehiyon na nakaugnay bilang isang singsing
• Kung nabigo ang isang link (hal., AZ1 hanggang AZ2), maaaring mapunta sa malayo (AZ1 hanggang AZ3 hanggang AZ2)
• Kino-convert ang problema sa availability sa isang latency na problema, na pinapanatili ang availability
• Napakahusay na modelo ng pag-iisip: pag-convert ng isang uri ng problema sa ibang uri ng problema (hal., availability sa latency)

Mga Hamon ng Fail-Stop Failures sa Stateful System

Mga Fail-Stop Failures sa Stateful System

• Nakakalito mangatwiran sa mga sistema tulad ng S3
• Maaaring humantong sa mga estado na kung hindi man ay hindi maabot ang
• Pag-crash Consistency
• Dapat bumalik ang system sa pare-parehong estado pagkatapos ng pagkabigo sa paghinto
• Halimbawa: pagsulat ng dalawang linya ng teksto sa isang file
• Normal na pagpapatupad: ang file ay may parehong linya
• Fail-stop failure sa panahon ng execution: ang file ay maaaring magkaroon lamang ng unang linya
• Pumapasok sa isang hindi maabot na estado sa kawalan ng pagkabigo
• Pagdidisenyo sa Paikot na Mga Estadong Hindi Maabot
• Sumulat ng isang papel sa Shodstor (software ng storage node) na tumutugon sa isyung ito
• Nakatuon sa pangangatwiran tungkol sa mga naaabot na estado sa pagkakaroon ng kabiguan at pagkakatugma

Paghawak ng Gray Failures

Mga Gray na Pagkabigo

• Mas kumplikadong mga mode ng pagkabigo na lampas sa fail-stop
• Halimbawa:
• Isang put request sa S3
• Ang kahilingan ay mula sa internet patungo sa isang S3 front-end server
• Ang data ng mga tagahanga ng front-end na server sa mga storage node ay
• Tinukoy na Mga Gray Failures
• Mga pagkabigo na hindi kumpleto (hal., fail-stop) ngunit nagiging sanhi ng hindi inaasahang pagkilos ng system
• Halimbawa: tumatanggap ang front-end na web server ng mga kahilingan ngunit hindi maabot ang ilang downstream na host dahil sa mga isyu sa networking
• Nagbabalik ang server ng mga error para sa mga nabigong kahilingan ngunit patuloy na tumatanggap at tumutugon sa mga kahilingan
• Gamit ang Muling Sinusubukang Pangasiwaan ang Mga Gray na Pagkabigo
• Napakahusay na diskarte: kung nabigo ang isang kahilingan, subukan itong muli sa ibang landas (hal., ibang front-end na web server)
• Ang mga AWS SDK ay may mga sopistikadong diskarte sa muling pagsubok na sinasadyang muling subukan ang mga kahilingan sa iba't ibang IP address
• Ang mga muling pagsubok ay nagbibigay-daan sa pagsubok ng ibang landas sa pamamagitan ng system na
• Mga Panganib ng Mga Muling Pagsubok sa Mga Naipamahagi na System
• Ang mga muling pagsubok ay maaaring humantong sa napakalaking pagpapalakas ng trabaho kung ang lahat ng mga serbisyo ay muling subukan ang mga nabigong kahilingan
• Halimbawa: ang pagkabigo sa ibaba ng stack ay maaaring magresulta sa 27 na beses na mas maraming pagsubok kaysa sa mga orihinal na kahilingan
• Maaaring mag-overload ang system ng labis na pag-ulit ng
• Intentional Design of Retry Strategies
• Kailangang maging sinasadya kapag nagdidisenyo ng mga diskarte sa muling pagsubok upang maiwasan ang labis na karga sa system
• Halimbawa: mas kaunting mga muling pagsubok o hindi na muling sumusubok sa ibaba ng stack, alam na ang mga muling pagsubok ay magaganap sa mas mataas
• Tinitiyak ang pagkakaroon habang pinoprotektahan ang system mula sa labis na muling pagsubok
• Mga Gray na Pagkabigo Dahil sa Pag-load
• Ang web server ay napuno ng trabaho, na nagpapakita bilang mabagal na mga kahilingan
• Napakahusay na mekanismo: mga timeout (nag-time out ang kliyente sa mga mabagal na kahilingan at sumusubok muli sa ibang lugar)
• Mga Hamon sa Mga Timeout
• Hindi perpekto at mahirap idisenyo ang mga timeout, lalo na sa mga muling pagsubok
• Halimbawa:
• Overloaded na web server na may pila ng mga kahilingan
• Nag-time out ang kliyente at muling sumusubok sa ibang lugar
• Ipinagpapatuloy ng server ang pagpoproseso ng kahilingang nag-time out, na hindi alam ang muling pagsubok ng kliyente
• Mga resulta sa server na gumagawa ng walang kwentang trabaho sa mga kahilingan ng mga kliyente na sumuko sa
• Congestive Collapse
• Sabihin kung saan pinoproseso lamang ng server ang mga kahilingan na na-time out at muling sinubukan sa ibang lugar
• Chain reaction effect: ang overloaded na server ay nagiging mas mabagal, na nagdudulot ng mas maraming pagsubok at queue buildup
• Siklo ng self-feeding kung saan ginugugol ng server ang lahat ng oras sa mga nabigong timeout mula sa mga muling pagsubok.
• Workaround: Inverted Queue Processing
• Mekanismo upang mahawakan ang mga overloaded na server na may buong pila
• Iproseso ang pila mula sa likod (huling pasok, una sa labas)
• Hindi patas ngunit pinaparusahan ang ilang kliyente na gawin ang iba nang napakabilis

Disenyo ng Self-Healing System

Paghuhukay ng Congestive Collapse

• Baliktad na pagpoproseso ng pila: iproseso ang pila mula sa likod (huling pasok, una sa labas)
• Nagbibigay-daan sa ilang kahilingan na magtagumpay, na binabawasan ang backlog ng mabagal na pag-time out na mga kahilingan
• I-backoff at subukang muli: umatras ang mga kliyente at subukang muli nang mas mabagal
• Nagbibigay ng oras sa server na humukay sa backlog na
• Metastable Failure Mode
• Sabihin kung saan ginugugol ng system ang lahat ng oras sa pagpoproseso ng mga naka-time out na kahilingan sa kabila ng orihinal na problema na niresolba sa
• System-Level Failure Recovery
• Layunin: S3 dapat pagalingin ang sarili nang walang manu-manong interbensyon
• Halimbawa: hindi matagumpay na tumutugon ang web server sa mga kahilingan
• Muling sumubok ang mga kliyente sa ibang lugar, ngunit kailangang alisin ang server sa serbisyo ng
• Mga Pagsusuri sa Kalusugan
• Mahalagang tool para sa awtomatikong pagpapagaling ng mga server
• Ang server ng health check ay nagpapadala ng mga kahilingan sa mga web server upang suriin ang functionality
• Kung nabigo ang server sa pagsusuri sa kalusugan, maaari itong alisin sa serbisyo (hal., alisin sa DNS)
• Pinapababa ang mga pagkabigo sa pamamagitan ng pagpigil sa mga kliyente na maabot ang mga nabigong server
• S3's Paggamit ng AWS Infrastructure
• S3 na binuo sa AWS gamit ang parehong imprastraktura na magagamit sa mga customer
• Kapasidad ng web server: mga balanse ng pag-load ng network
• DNS: Ruta 53
• Ipinatupad ang mga pagsusuri sa kalusugan gamit ang mga NLB at Ruta 53

Pagtitiyak ng Matatag na Pagsusuri sa Kalusugan at Pandaigdigang View ng System Health

Panganib ng Single Health Check

• Maaaring mabigo ang server ng pagsusuri sa kalusugan, na humahantong sa maling pagtuklas ng mga pagkabigo sa web server
• Halimbawa: ang health check server na may isyu sa network ay nagmamarka sa lahat ng web server bilang masama
• Kailangang magdisenyo para sa pagkakaroon ng parehong mga server at sistema ng pagsusuri sa kalusugan ng Maramihang Mga Pananaw para sa
• Mga Pagsusuri sa Kalusugan
• Gumagamit si S3 ng mga pagsusuri sa kalusugan mula sa maraming mapagkukunan:
• Parehong rehiyon
• Iba't ibang rehiyon
• Pampublikong internet
• Pinagsasama-sama ang mga signal upang bumuo ng isang detalyadong view ng kalusugan ng web server
• Tumutulong sa pag-diagnose ng mga nauugnay na pagkabigo (hal., mga isyu sa networking)
• Pag-iwas sa Mga Lokal na Desisyon
• Mahalagang prinsipyo: huwag hayaan ang mga lokal na sistema na gumawa ng mga lokal na desisyon tungkol sa kalusugan ng serbisyo
• Halimbawa: orihinal na pagsusuri sa kalusugan na gumagawa ng lokal na desisyon batay sa pananaw nito sa system
• Ang mga distributed system ay nangangailangan ng pandaigdigang pananaw upang maiwasan ang mga pagkakamali sa mga lokal na desisyon
• Global View ng System Health
• Halimbawa: pag-detect at pagsasaayos ng mga bagsak na hard drive
• Nakikita ng software ang pagbagsak ng hard drive
• Nagti-trigger ng remediation (hal., power cycle, pagpapalit ng technician) Global Rate Limiter para sa Health Checks
• Ang serbisyo sa pagsusuri sa kalusugan ay dapat kumunsulta sa isang global rate limiter bago gumawa ng mga pagbabago sa system
• Halimbawa: nakita ng pagsusuri sa kalusugan ang bagsak na hard drive at gustong alisin ito sa serbisyo
• Pinipigilan ng Rate limiter ang labis na pag-alis ng mga hard drive kung ang serbisyo sa pagsusuri sa kalusugan ay magiging magulo
• Recap of Designing for Availability
• Tukuyin ang kakayahang magamit at tama ang mga layunin
• Idisenyo ang pangkalahatang arkitektura ng system upang maabot ang mga layunin (hal., arkitektura na nakabatay sa korum, malakas na pagkakapare-pareho)
• Ipatupad ang mga piraso ng system na may pag-unawa sa mga mode ng pagkabigo at remediation nang walang mga lokal na desisyon