Bekijk Volledige Versie : Amazon EC2 reboots
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/logglys-outage-for-december-19th/
http://support.scalr.net/discussions/problems/3511-performace-issues-after-aws-global-reboot
https://forums.aws.amazon.com/thread.jspa?threadID=82343
http://www.elastician.com/2011/12/dont-reboot-me-bro.html
http://www.crn.com/news/cloud/232300111/widespread-amazon-ec2-cloud-instance-reboots-spark-questions-concerns.htm;jsessionid=+V+MTlk1i0alruzZxKz2jw**.e cappj03
"OKE".
Dat kan toch, (vooral) als het aangekondigd is?
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.
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...
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.
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?! ;)
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.
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.
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.
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.
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.
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).
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
26/12/11, 16:01
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'.
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'.
Dat zou ik dan eerder het toekomstbeeld van de cloud willen noemen. In de praktijk is dat namelijk nog ondoenlijk - en daarmee doel ik voornamelijk op het synchroon repliceren van data over langere afstanden.
Verder helemaal met je eens, behalve je opmerking over 'je website herontwerpen'. Dat is totaal ongerelateerd, het gaat namelijk enkel om de infrastructuur waar je website op draait (en als je het goed doet, hoeft er daarvoor letterlijk niets aan een website aangepast te worden).
systemdeveloper
27/12/11, 13:23
Dat zou ik dan eerder het toekomstbeeld van de cloud willen noemen. In de praktijk is dat namelijk nog ondoenlijk - en daarmee doel ik voornamelijk op het synchroon repliceren van data over langere afstanden.
Verder helemaal met je eens, behalve je opmerking over 'je website herontwerpen'. Dat is totaal ongerelateerd, het gaat namelijk enkel om de infrastructuur waar je website op draait (en als je het goed doet, hoeft er daarvoor letterlijk niets aan een website aangepast te worden).
En daar kijk je imho dan naar de technische kant van de cloud, niet naar het gebruik van een cloud. De technische problemen (replicatie e.d.) zijn deels afhankelijk van software, deels van hardware en een niet onaanzienlijk deel puur van natuurwetten. Een bitje over 100km doet er gewoon langer over dan een bitje over 15cm.
Zolang we geen quantum entanglement routers hebben, zal daar ook niks aan veranderen.
Kijk naar die grote amazon storing een aantal maanden geleden. Mensen dachten toen dat de cloud wel even zorgde dat hun zooi magisch ergens anders verder draaide, maar dat deed het alleen bij de personen die de cloud juist gebruikten. De enkele 'vpsjes' waren gewoon plat en de websites erop ook. Dus als je NU in real life een cloud wilt gebruiken op een manier dat je niet plat gaat als bij een uitval, zal je toch echt je code in moeten duiken.
En daar kijk je imho dan naar de technische kant van de cloud, niet naar het gebruik van een cloud.
De mogelijkheden van het gebruik van de cloud zijn beperkt door de technische kant.
De technische problemen (replicatie e.d.) zijn deels afhankelijk van software, deels van hardware en een niet onaanzienlijk deel puur van natuurwetten.
Replicatie is feitelijk het enige echte struikelblok. Dit is weer relevant voor iedere database toepassing (tenzij het om een database gaat waar nauwelijks naar geschreven wordt). Ik doelde daarmee op een voorbeeld wat jij zelf noemde; databases verspreid over meerdere werelddelen. In de praktijk is dat nog niet echt mogelijk (er zijn wel oplossingen te bedenken met beperkingen/tekortkomingen).
Dus als je NU in real life een cloud wilt gebruiken op een manier dat je niet plat gaat als bij een uitval, zal je toch echt je code in moeten duiken.
Niet in de code van je website, maar in de code van de achterliggende infrastructuur. Aan de parameters en structuur van een applicatie hoeft in principe helemaal niets te veranderen, omdat de applicaties de daemons als lokaal zien.