Amazon EC2 reboots

[redbeenl]

Gisteren kreeg ik een berichtje van een van een kennis dat een van zijn EC2 servers was herstart. Deze kwam niet meer goed op, dus of ik misschien even kon helpen. Dat was snel opgelost, maar bij het onderzoeken bleek dat de instance een "nette" reboot had gekregen, maar dat er niemand ingelogd was op dat moment. De enige mogelijkheid was dus dat Amazon de reboot geinitieerd had. Nu las ik op een aantal sites dat Amazon met een grootschalige reboot actie bezig is en dat ook grote Amazon klanten hier last van hebben gehad. Zelf gebruik ik slechts sporadisch AWS dus ik heb de aankondiging zelf niet ontvangen, maar de meldingen die Amazon uitgestuurd heeft blijken soms in spamfilters te blijven hangen

Dit blijkt al begin december aangekondigd te zijn, maar nog steeds te lopen. Ook niet zo gek met zoveel instances.

http://loggly.com/blog/2011/12/loggl...december-19th/
http://support.scalr.net/discussions...-global-reboot
https://forums.aws.amazon.com/thread...threadID=82343
http://www.elastician.com/2011/12/do...ot-me-bro.html
http://www.crn.com/news/cloud/232300...2jw**.ecappj03

[BReady]

"OKE".

Dat kan toch, (vooral) als het aangekondigd is?

[Stewie]

Ja kan dat? Met kerst?

[Wido]

Ja kan dat? Met kerst?

Het is zondag pas kerst

Ik vind dit ook kunnen, als zij een kritiek lek ontdekken waarvoor grootschalige reboots nodig zijn, dan moet dat gewoon gebeuren. Zoiets eindeloos blijven uitstellen omdat de klant niet wil rebooten werkt niet.

Zeker in een omgeving als EC2 weet je dat je VM soms gewoon uit kan vallen en op een andere node online komt.

[davinci]

keurig 5 dagen voor de geplande reboot aangekondigd.. zowel via mail, als in de console als via de api...
en als je voor die 5 dagen zelf een reboot had gedaan was de fix ook uitgerold..
ik zie het probleem niet zo...

[Apoc]

Het probleem is m.i. vooral dat er nogal wat mensen zijn die naar AWS kijken alsof het de heilige graal van de hosting industrie is, terwijl er in realiteit talloze oplossingen zijn die veel beter zijn. Er wordt naar gekeken alsof er onmogelijk is mis mee kan gaan, of dat er bijvoorbeeld een reboot nodig zou zijn. AWS is in dat opzicht zwaar overrated.

[davinci]

iedereen die aws (serieus) gebruikt, weet dat je rekening moet houden met het feit dat het ooit 'mis kan gaan'.
Net zoals iedereen bij z'n reguliere webhoster toch ook zelf offsite backups maakt.... toch?!

[Stewie]

Het is zondag pas kerst

Ik vind dit ook kunnen, als zij een kritiek lek ontdekken waarvoor grootschalige reboots nodig zijn, dan moet dat gewoon gebeuren. Zoiets eindeloos blijven uitstellen omdat de klant niet wil rebooten werkt niet.

Zeker in een omgeving als EC2 weet je dat je VM soms gewoon uit kan vallen en op een andere node online komt.

Onze grote klanten hebben een change freeze van 3 tot 4 weken, voor dit type klanten is dit gewoon killing en daardoor kiezen zij bewust niet voor "cloud" waarin het ontastbaar is waar je server draait en welke dependencies het systeem heeft.

[Apoc]

Onze grote klanten hebben een change freeze van 3 tot 4 weken, voor dit type klanten is dit gewoon killing en daardoor kiezen zij bewust niet voor "cloud" waarin het ontastbaar is waar je server draait en welke dependencies het systeem heeft.

Naar mijn mening heeft dit niets met cloud/niet-cloud te maken. Kwestie van goede afspraken maken.

[Stewie]

Naar mijn mening heeft dit niets met cloud/niet-cloud te maken. Kwestie van goede afspraken maken.

Dat is dus het probleem van cloud. Bij amazon is het zo groot dat jij er geen enkele zeggenschap hebt. Als het een dedicated server is, tastbaar, dan is het "hands off" als de klant dat wilt of eist.

[Apoc]

Dat is dus het probleem van cloud. Bij amazon is het zo groot dat jij er geen enkele zeggenschap hebt. Als het een dedicated server is, tastbaar, dan is het "hands off" als de klant dat wilt of eist.

Dat is geen probleem van cloud, dat is een probleem van Amazon. Wat jij omschrijft kan absoluut niet in algemene zin over ieder willekeurige cloud gezegd worden. Er zijn genoeg cloud providers waar je gewoon strakke afspraken mee kunt maken.

[Stewie]

Dat is geen probleem van cloud, dat is een probleem van Amazon. Wat jij omschrijft kan absoluut niet in algemene zin over ieder willekeurige cloud gezegd worden. Er zijn genoeg cloud providers waar je gewoon strakke afspraken mee kunt maken.

Klopt, maar Amazon is groot en trendsetter en zet hiermee wel de toon waardoor klanten die dit meemaken wantrouwig worden. Als jouw bedrijf niet zo is moet jij vervolgens moeite doen om de klant te overtuigen dat je niet op die manier werkt.

[Apoc]

Klopt, maar Amazon is groot en trendsetter en zet hiermee wel de toon waardoor klanten die dit meemaken wantrouwig worden. Als jouw bedrijf niet zo is moet jij vervolgens moeite doen om de klant te overtuigen dat je niet op die manier werkt.

Dat is het grote nadeel van de term "de cloud". Vooral het "de" gedeelte heb ik een enorme hekel aan. Alsof er maar 1 cloud is (wat weer de suggestie wekt dat de dienstverlening van iedere cloudprovider precies hetzelfde is).

[davinci]

die afspraken kan je voor bepaalde zaken in AWS prima maken.. Wij hebben keurige maintenance windows afgesproken voor onze database servers (1x per week op dinsdagnacht tussen 3:00 en 3:30)

[systemdeveloper]

Nou, ze noemen het 'de cloud' omdat dit een methode is om je applicaties/sites/bedrijf te bouwen. Het heeft verder niet veel te maken met het feit dat o.a. amazon een shitload hardware wereldwijd uitrolt en het 'de cloud' noemt.

Je bedrijf 'onderbrengen in een cloud' betekent ook niet dat je een paar racks fysieke servers migreert naar een vpsplatform om wat the schedelen tussen een zooi 'goed opgezette jails'. In feite is DAT namelijk niks anders dan efficienter resource management.

Je bedrijf/website/whatever in 'de cloud' stoppen betekent dat je je processen moet herstruktureren, je website herontwerpen en je online aps en zooi 'uitvalbestendig' gaat maken.
In het geval van de cloud van bv. amazon ga je dus ook niet 1 vps aanmaken, je website erop gooien en 'Ik ben gecloudificeerd' jubelen. Je gaat 10 cheap instanties aanmaken, die je betaalt op basis van use en die je gaat inzetten om te zorgen dat je onheil beperkt ( web, lb, db, cache, etc in 2 verschillende zones ). Als je dat doet, dan zit je pas in de cloud. En als je het goed doet dan zal het je een rotzorg zijn als de helft van je systeem om een zelfs een werelddeel 'uitvalt'.