Amazon RedShift er et datavarehus som kan utvides til exabyte-skala. I dag er titusenvis av AWS-kunder (inkludert NTT DOCOMO, fintog Johnson & Johnson) bruk Amazon Redshift til å kjøre virksomhetskritiske dashbord for forretningsintelligens, analysere strømmedata i sanntid og kjøre prediktive analysejobber.
Amazon Redshift driver analytiske arbeidsbelastninger for Fortune 500-selskaper, startups og alt i mellom. Med den konstante økningen i genererte data, fortsetter Amazon Redshift-kunder å oppnå suksesser i å levere bedre service til sluttbrukerne, forbedre produktene deres og drive en effektiv og effektiv virksomhet. Tilgjengelighet er derfor nøkkelen for å fortsette å drive kundesuksess, og AWS vil bruke kommersielt rimelige anstrengelser for å gjøre Amazon Redshift tilgjengelig med en månedlig oppetidsprosent for hver multi-node-klynge, under enhver månedlig faktureringssyklus, på minst 99.9 % (vår "Serviceforpliktelse").
I dette innlegget presenterer vi en løsning for å hjelpe deg med å gi en forutsigbar og repeterbar opplevelse til Amazon Redshift-sluttbrukerne ved å ta kontroll over gjentatte Amazon Redshift-vedlikeholdsvinduer.
Amazon Redshift vedlikeholdsvinduer
Amazon Redshift utfører periodisk vedlikehold for å bruke rettelser, forbedringer og nye funksjoner på klyngen din. Denne typen vedlikehold skjer i løpet av 30 minutter vedlikeholdsvindu sett som standard per region fra en 8-timers blokk på en tilfeldig ukedag. Du bør endre det planlagte vedlikeholdsvinduet i henhold til forretningsbehovene dine ved å endre klyngen, enten programmatisk eller ved å bruke Amazon Redshift-konsollen. Vinduet skal være minst 30 minutter og ikke lenger enn 24 timer. For mer informasjon, se Administrere klynger ved hjelp av konsollen.
Hvis en vedlikeholdshendelse er planlagt for en gitt uke, starter den i løpet av det tildelte 30-minutters vedlikeholdsvinduet. Mens Amazon Redshift utfører vedlikehold, avslutter den alle forespørsler eller andre operasjoner som pågår. Hvis det ikke er noen vedlikeholdsoppgaver å utføre i løpet av det planlagte vedlikeholdsvinduet, fortsetter klyngen å fungere normalt til neste planlagte vedlikeholdsvindu. Amazon Redshift bruker Amazon enkel varslingstjeneste (Amazon SNS) for å sende varsler om Amazon Redshift-hendelser. Du aktiverer varsler ved å opprette en Amazon Redshift-hendelse abonnement. Du kan lage en Amazon Redshift hendelsesvarsling abonnement slik at du kan bli varslet når en hendelse inntreffer for en gitt klynge.
Når en Amazon Redshift-klynge er planlagt for vedlikehold, mottar du en Amazon Redshift «Venter»-hendelse, som beskrevet i følgende tabell.
Amazon Redshift kategori | Event ID | Hendelsens alvorlighetsgrad | Beskrivelse |
---|---|---|---|
Venter | REDSHIFT-EVENT-2025 | INFO | Databasen din for klyngen vil bli oppdatert mellom og . Klyngen din vil ikke være tilgjengelig. Planlegg deretter. |
Venter | REDSHIFT-EVENT-2026 | INFO | Din klynge vil bli oppdatert mellom og . Klyngen din vil ikke være tilgjengelig. Planlegg deretter. |
Amazon Redshift gir deg også muligheten til å omplanlegge klyngens vedlikeholdsvindu ved å utsette ditt kommende vedlikehold med opptil 45 dager. Dette alternativet er spesielt nyttig hvis du ønsker å maksimere klyngens oppetid ved å utsette et fremtidig vedlikeholdsvindu. For eksempel, hvis klyngens vedlikeholdsvindu er satt til onsdag 8:30–9:00 UTC og du må ha ustanselig tilgang til klyngen i de neste 2 ukene, kan du utsette vedlikeholdet til en dato 2 uker fra nå. Vi utfører ikke noe vedlikehold på klyngen din når du har spesifisert en utsettelse.
Å utsette et vedlikeholdsvindu gjelder ikke for obligatoriske Amazon Redshift-oppdateringer, for eksempel viktige sikkerhetsoppdateringer. Planlagt vedlikehold er forskjellig fra Amazon Redshift obligatorisk vedlikehold. Hvis Amazon Redshift trenger å oppdatere maskinvare eller gjøre andre obligatoriske oppdateringer i løpet av utsettelsesperioden, varsler vi deg og gjør de nødvendige endringene. Klyngen din er ikke tilgjengelig under disse oppdateringene, og slikt vedlikehold kan ikke utsettes. Hvis en maskinvareutskifting er nødvendig, mottar du en hendelsesvarsling gjennom AWS Management Console og SNS-abonnementet ditt som et «ventende» element, som vist i tabellen nedenfor.
Amazon Redshift kategori | Event ID | Hendelsens alvorlighetsgrad | Beskrivelse |
---|---|---|---|
Venter | REDSHIFT-EVENT-3601 | INFO | En node på klyngen din vil bli erstattet mellom og . Du kan ikke utsette dette vedlikeholdet. Planlegg deretter. |
Venter | REDSHIFT-EVENT-3602 | INFO | En node på klyngen din er planlagt erstattet mellom og . Klyngen din vil ikke være tilgjengelig. Planlegg deretter. |
Utfordring
Etter hvert som antallet Amazon Redshift-klynger du administrerer for en analyseapplikasjon vokser, blir sluttbrukeropplevelsen svært avhengig av regelmessig vedlikehold. Dette betyr at du vil sørge for at vedlikeholdsvinduer på tvers av alle klynger skjer på samme tid og faller på samme dag hver måned. Du vil unngå en situasjon der for eksempel dine fem Amazon Redshift-klynger oppdateres på en annen dag eller uke. Til syvende og sist vil du gi Amazon Redshift-sluttbrukerne et uavbrutt antall dager der klyngene ikke er underlagt noe planlagt vedlikehold. Dette gir deg muligheten til å kunngjøre et planlagt vedlikehold til brukerne dine i god tid før vedlikeholdsdatoen.
Amazon Redshift-klynger er planlagt for vedlikehold avhengig av flere faktorer, inkludert når en klynge ble opprettet og dens region. For eksempel kan du ha to klynger på samme Amazon Redshift-versjon som er planlagt for forskjellige vedlikeholdsvinduer. Regioner implementerer Amazon Redshift nyeste versjoner og oppdateringer til forskjellige tider. En klynge som løper inn us-east-1
kan være planlagt for det samme vedlikeholdet 1 uke før en annen klynge inn eu-west-1
. Dette gjør det vanskeligere for deg å gi sluttbrukerne en forutsigbar vedlikeholdsplan.
For å løse dette problemet må du vanligvis sjekke og synkronisere vedlikeholdsvinduene på tvers av alle klyngene dine til et bestemt tidspunkt, for eksempel sat:06:00-sat:06:30
. I tillegg vil du unngå å ha klynger planlagt for vedlikehold med forskjellige intervaller. For det må du utsette vedlikehold på tvers av alle klyngene dine til å falle på samme dag. Du kan for eksempel utsette alt vedlikehold på tvers av alle klynger til å skje 1 måned fra nå, uavhengig av når klyngen sist ble oppdatert. På denne måten vet du at klyngene dine ikke er planlagt for vedlikehold de neste 30 dagene. Dette gir deg nok tid til å kunngjøre vedlikeholdsplanen til Amazon Redshift-brukerne.
Løsningsoversikt
Å ha én dag i måneden når Amazon Redshift-planlagt vedlikehold skjer på tvers av alle klyngene dine, gir brukerne en sømløs opplevelse. Det gir deg kontroll og forutsigbarhet over når klynger ikke er tilgjengelige. Du kan kunngjøre dette vedlikeholdsvinduet på forhånd for å unngå plutselige avbrudd.
Følgende løsning distribuerer en AWS Lambda funksjon (RedshiftMaintenanceSynchronizer
) til AWS-kontoen din. Funksjonen kjører på en tidsplan som kan konfigureres gjennom en AWS skyformasjon malparameterfrekvens for å kjøre hver 6., 12. eller 24. time. Denne funksjonen synkroniserer vedlikeholdsplaner på tvers av alle Amazon Redshift-klynger for å skje på samme tid på samme dag. Det gir deg også muligheten til å utsette alle fremtidige vedlikeholdsvinduer på tvers av alle klynger med et antall dager (utsettelsesdager) i opptil 45 dager. Dette lar deg gi brukerne dine et uavbrutt antall dager når klyngene dine ikke er gjenstand for vedlikehold.
Vi bruker følgende inngangsparametere:
- Utsettelsesdager – Antall dager for å utsette alle fremtidige planlagte vedlikeholdsvinduer. Amazon Redshift kan utsette vedlikeholdsvinduer med opptil 45 dager. Løsningen legger dette nummeret til datoen for siste vellykket fullførte vedlikehold på tvers av noen av dine klynger. Den resulterende datoen er den nye vedlikeholdsdatoen for alle klyngene dine.
- Frekvens – Frekvensen for å kjøre denne løsningen. Du kan konfigurere den til å kjøre hver 6., 12. eller 24. time.
- dag – Den foretrukne ukedagen for å planlegge vedlikeholdsvinduer.
- time – Den foretrukne timen på dagen for å planlegge vedlikeholdsvinduer (24-timers format).
- Minutt – Det foretrukne minuttet i timen for å planlegge vedlikeholdsvinduer.
Lambdafunksjonen utfører følgende trinn:
- Viser alle Amazon Redshift-klynger i regionen.
- Oppdaterer vedlikeholdsvinduet for alle klynger til samme verdi som inndataparametere for dag/time/minutt fra CloudFormation-malen.
- Sjekker for det siste vellykket fullførte vedlikeholdet på tvers av alle klynger.
- Beregner utsettelsesvedlikeholdsdatoen ved å legge inndataparameteren for utsettelse til datoen for siste vellykket fullførte vedlikehold. For eksempel, hvis utsettelsesparameteren er 30 dager og siste vellykkede vedlikeholdsvindu fullført 1. juli 2020, er neste vedlikeholdsdato for utsettelse 31. juli 2020.
- Utsetter neste vedlikeholdsvindu på tvers av alle klynger til utsettelsesdatoen som ble beregnet i forrige trinn.
Start løsningen
For å komme i gang, distribuer cloudFormation-malen til AWS-kontoen din.
- Til Stabelnavn, skriv inn et navn for stabelen din for enkel referanse.
- Til dag, velg ukedagen for vedlikeholdsvinduet.
- Til time, velg timen for vinduet skal starte.
- Til Minutt, velg minuttet innenfor timen for vinduet skal starte.
Vinduet ditt skal være et tidspunkt med minst klyngeaktivitet og i rushtiden.
- Til Utsettelsesdager, velg antall dager for å utsette alle fremtidige planlagte vedlikeholdsvinduer.
- Til Løsning Kjør Frekvens, velg frekvensen 6, 12 eller 24 timer.
Etter at malen er implementert, er følgende ressurser tilgjengelige:
- RedshiftMaintenanceSync Lambda-funksjonen. Dette er en Python 3.8 Lambda-funksjon som synkroniserer og utsetter vedlikeholdsvinduene på tvers av alle Amazon Redshift-klynger.
- RedshiftMaintenanceSyncEventRule Amazon CloudWatch hendelsesregel. Denne regelen utløses på en tidsplan basert på inndataparameteren Frekvens. Den utløser RedshiftMaintenanceSync Lambda-funksjonen for å kjøre løsningslogikken.
Når Lambda-funksjonen starter og oppdager en allerede tilgjengelig utsettelse på noen av klyngene dine, prøver den ikke å endre den eksisterende utsettelse, og avsluttes i stedet.
Løsningen logger enhver utsettelse den utfører på en hvilken som helst klynge i den tilknyttede CloudWatch-logggruppen.
Synkroniser og utsett vedlikeholdsvinduer
For å demonstrere denne løsningen har jeg to Amazon Redshift-klynger med forskjellige foretrukne vedlikeholdsvinduer og planlagte intervaller.
Klynge A (se følgende skjermbilde) har et foretrukket vedlikeholdsvindu satt til fredag kl. 4:30–5:00. Det er planlagt vedlikehold om 2 dager.
Klynge B har et foretrukket vedlikeholdsvindu satt til tirsdag kl. 9:45–10:15. Den er planlagt for vedlikehold om 6 dager.
Dette betyr at Amazon Redshift-brukerne mine har en 30-minutters avbrudd to ganger i løpet av de neste 2 og 6 dagene. Dessuten skjer disse avbruddene på helt andre tidspunkt.
La oss lansere løsningen og se hvordan klyngevedlikeholdsvinduene og planleggingsintervallene endres.
Lambda-funksjonen gjør følgende hver gang den kjører:
- Viser alle klyngene.
- Sjekker om noen av klyngene har en utsettelse aktivert og avslutter hvis den finner noen.
- Synkroniserer alle foretrukne vedlikeholdsvinduer på tvers av alle klynger for å falle på samme tid og ukedag.
- Sjekker for siste vellykket fullførte vedlikeholdsdato.
- Legger utsettelsesdagene til siste vedlikeholdsdato. Dette blir den nye utsettelsesdatoen.
- Bruker den nye utsettelsesdatoen for alle klynger.
Klynge A sitt vedlikeholdsvindu ble synkronisert med inngangsparametrene jeg sendte til CloudFormation-malen. I tillegg ble neste vedlikeholdsvindu utsatt til 21. juni 2021, 8:06 (UTC +02:00).
Klynge Bs vedlikeholdsvindu synkroniseres også til samme verdi fra klynge A, og neste vedlikeholdsvindu ble utsatt til samme dag som klynge A: 21. juni 2021, 8:06 (UTC +02:00).
Til slutt, la oss sjekke CloudWatch-logggruppen for å forstå hva løsningen gjorde.
Nå har begge klyngene samme vedlikeholdsvindu og neste planlagte vedlikehold, som er en måned fra nå. I et produksjonsscenario gir dette deg nok ledetid til å kunngjøre vedlikeholdsvinduet til Amazon Redshift-sluttbrukerne og gi dem den nøyaktige dagen og klokkeslettet når klynger ikke er tilgjengelige.
Oppsummering
Denne løsningen kan hjelpe deg med å gi en forutsigbar og repeterbar opplevelse til Amazon Redshift-sluttbrukerne ved å ta kontroll over periodiske Amazon Redshift-vedlikeholdsvinduer. Det lar deg gi brukerne dine et uavbrutt antall dager der klynger alltid er tilgjengelige – med unntak av planlagte obligatoriske oppgraderinger. Klikk her. for å komme i gang med Amazon Redshift i dag.
om forfatteren
Ahmed Gamaleldin er Senior Technical Account Manager (TAM) hos Amazon Web Services. Ahmed hjelper kunder med å kjøre optimaliserte arbeidsbelastninger på AWS og få det beste ut av skyreisen deres.
- "
- &
- 107
- 2020
- 2021
- 9
- adgang
- Logg inn
- Alle
- Amazon
- Amazon Web Services
- analytics
- Søknad
- tilgjengelighet
- AWS
- BEST
- fakturering
- grensen
- virksomhet
- business intelligence
- endring
- Cloud
- Selskaper
- fortsette
- fortsetter
- Opprette
- Kundesuksess
- Kunder
- dato
- datalager
- Database
- dag
- levere
- gJORDE
- Effektiv
- Event
- hendelser
- Expand
- Egenskaper
- funn
- format
- Fredag
- funksjon
- framtid
- Gruppe
- maskinvare
- Hvordan
- HTTPS
- Inkludert
- Øke
- informasjon
- Intelligens
- IT
- Jobb
- Juli
- nøkkel
- siste
- lansere
- føre
- ledelse
- Nye funksjoner
- varsling
- Drift
- Opportunity
- Alternativ
- Annen
- Patches
- Prediktiv Analytics
- presentere
- Produksjon
- Produkter
- Python
- sanntids
- Ressurser
- Kjør
- rennende
- sømløs
- sikkerhet
- Tjenester
- sett
- Enkelt
- So
- LØSE
- Begynn
- startet
- startups
- streaming
- abonnement
- suksess
- vellykket
- TAM
- Teknisk
- tid
- Oppdater
- oppdateringer
- Brukere
- verdi
- Warehouse
- web
- webtjenester
- uke
- vinduer
- innenfor
- Arbeid