Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 76 reacties
Submitter: Steeph

Als gevolg van een stroomstoring heeft een datacenter van Amazon in Dublin in de nacht van zondag op maandag zonder elektriciteit gezeten. Als gevolg hiervan waren veel sites die bij Amazons Elastic Cloud-dienst werden gehost offline.

De stroomstoring ontstond nadat een transformatorhuisje van het datacenter werd geraakt door blikseminslag. Door de inslag ontstond een explosie, gevolgd door brand. Hoewel een stroomonderbreking doorgaans zou moeten worden overgepakt door een noodgenerator, bleek dat de impact zo krachtig was geweest dat ook het controlesysteem van de stroomfases werd lamgelegd. Dit systeem zorgt ervoor dat de noodgenerator wordt gesynchroniseerd. Zonder deze fasesynchronisatie kunnen generators niet automatisch worden ingeschakeld, waardoor een handmatige actie was vereist.

Volgens Amazon ontstond de storing zondagavond rond 20 uur en waren de gevolgen maandagochtend nog niet helemaal opgelost. Door de storing waren zowel de Elastic Compute Cloud als de Relational Database Service van Amazon offline. Hoewel de stroom in het datacenter binnen enkele uren was hersteld, bleek dat het terug online brengen van de diverse instances langer duurde dan gedacht. Een deel van de instances kwam vanzelf weer online, maar het resterende deel moest hierbij geholpen worden. Rond half zeven maandagochtend was 75 procent van de instances van de zogenoemde Availablity Zone van Amazon weer beschikbaar. Op het moment van publicatie waren de gevolgen van de storing nog niet overal verholpen.

Amazon heeft het bewuste datacenter in Dublin in 2008 in gebruik genomen. Volgens het bedrijf zouden hiermee vooral Europese bedrijven geholpen zijn, die niet langer aangewezen waren op een datacenter in de VS als zij met Amazon in zee wilden gaan. Een locatie in Europa zou niet alleen leiden tot lagere responstijden, maar mogelijk ook in sommige gevallen noodzakelijk zijn; bijvoorbeeld omdat data Europa niet mag verlaten. Microsoft heeft om dezelfde reden een datacenter in Dublin, dat naar verluidt ook is getroffen door de stroomstoring. Hierdoor zouden BPOS-klanten problemen hebben gekregen. Microsoft heeft in Amsterdam ook een datacenter, waardoor Nederlandse klanten waarschijnlijk geen hinder hebben ondervonden.

Hoewel veel bedrijven de uptime van de clouddiensten bij Amazon en soortgelijke aanbieders prijzen, is dit de tweede storing bij Amazon in korte tijd. In april dit jaar werd de aanbieder ook al getroffen door een forse downtime van zijn clouddiensten. De problemen bij het Elastic Compute Cloud-platform van Amazon zouden destijds zijn ontstaan door een foutieve upgrade-procedure, vermoedelijk het gevolg van een menselijke fout.

Na de storing in april heeft Amazon zijn excuses aangeboden aan zijn klanten. Ook beloofde het bedrijf dat klanten die door de storing zijn getroffen compensatie krijgen; zij kunnen tien dagen kosteloos gebruikmaken van Amazons clouddiensten. Het is overigens nog maar de vraag of Amazon bij de storing van afgelopen nacht het boetekleed aantrekt. Het bedrijf zou kunnen stellen dat het al het mogelijke doet om de uptime te garanderen, maar dat er tegen overmacht door weersinvloeden weinig is te doen.

Klanten die Amazon op basis van de service level agreements willen aanspreken op zijn verantwoordelijkheden, komen mogelijk ook van een koude kermis thuis. Amazon heeft als voorwaarde in zijn SLA opgenomen dat, om in aanmerking te komen voor de compensatieregeling, de storing diverse Availablity Zones moet hebben getroffen en de beschikbaarbeid op jaarbasis beneden de 99,95 procent moet zijn gezakt, wat neerkomt op ruim 4 uur downtime. Hoewel de storing zich in een datacenter voordeed, beschikt de faciliteit in Dublin over drie van dergelijke Availability Zones. Het is niet bekend of al deze drie zones gelijktijdig en langdurig onbeschikbaar zijn geweest. Amazon adviseert overigens om een failover in te richten in een datacenter in een andere geografische regio om downtime als gevolg van een storing in een andere regio te beperken, al betekent dit voor veel bedrijven wel een forse stijging van de kosten.

Moderatie-faq Wijzig weergave

Reacties (76)

Ook leuk, ik krijg net een mailtje van Amazon, dat er ook nog eens problemen zijn geweest met de EBS software in de EU-West Regio, waardoor een deel van mijn snapshots corrupt zijn geraakt:
Hello,

We've discovered an error in the Amazon EBS software that cleans up unused snapshots. This has affected at least one of your snapshots in the EU-West Region.

During a recent run of this EBS software in the EU-West Region, one or more blocks in a number of EBS snapshots were incorrectly deleted. The root cause was a software error that caused the snapshot references to a subset of blocks to be missed during the reference counting process. This process compares the blocks scheduled for deletion to the blocks referenced in customer snapshots. As a result of the software error, the EBS snapshot management system in the EU-West Region incorrectly thought some of the blocks were no longer being used and deleted them. We've addressed the error in the EBS snapshot system to prevent it from recurring.

We have now disabled all of your snapshots that contain these missing blocks. You can determine which of your snapshots were affected via the AWS Management Console or the DescribeSnapshots API call. The status for any affected snapshots will be shown as "error."

We have created copies of your affected snapshots where we've replaced the missing blocks with empty blocks. You can create a new volume from these snapshot copies and run a recovery tool on it (e.g. a file system recovery tool like fsck); in some cases this may restore normal volume operation. These snapshots can be identified via the snapshot Description field which you can see on the AWS Management Console or via the DescribeSnapshots API call. The Description field contains "Recovery Snapshot snap-xxxx" where snap-xxx is the id of the affected snapshot. Alternately, if you have any older or more recent snapshots that were unaffected, you will be able to create a volume from those snapshots without error. For additional questions, you may open a case in our Support Center: https://aws.amazon.com/support/createCase

We apologize for any potential impact this might have on your applications.

Sincerely,
AWS Developer Support
Afgelopen nacht heeft Microsoft deze mail naar BPOS klanten verzonden waarin men aangeeft eenmalig 25% korting te geven.
Geachte klant:

Microsoft Online Services streeft ernaar al haar klanten een uitzonderlijke service te leveren. Op 7 augustus hebben klanten die service verleend wordt vanuit de Dublin data center toegang verloren tot de services die onderdeel zijn van de Business Productivity Online Standard Suite. Wij verontschuldigen ons voor de nadelen die dit u en uw werknemers mogelijk heeft gebracht.

Wij zijn vastbesloten met onze klanten op een in een open en eerlijke manier te communiceren wanneer er service onderbrekingen zijn en de stappen die we nemen om herhalingen te voorkomen.
• Wat is er gebeurd?
o Uit vooronderzoek blijkt dat een grootschalige stroomstoring in Dublin voor toegangsproblemen tot het BPOS datacenter zorgde.
o Normaal gesproken nemen onze noodgeneratoren de benodigde belasting naadloos over, maar de bijkomende stroomstoot was zo groot dat deze doorgegeven werd aan een deel van onze noodgeneratoren.
o Teneinde de elektriciteit te herstellen, moesten we handmatig de noodgeneratoren synchroniseren, met als resultaat een vertraging in onze service verlening.
o Onze “Service Health Dashboard” werd regelmatig bijgewerkt gedurende deze herstellingswerkzaamheden, zodat onze klanten op de hoogte waren van het probleem.
• Welke acties zijn er genomen om herhaling te voorkomen?
o De BPOS Service werk vanuit onze in-huis energie generator faciliteiten, welke hoog beschikbaarheidsfaciliteiten zijn.
o We monitoren de algemene stroom generatie zeer nauwkeurig teneinde service te waarborgen aan onze klanten.
Wij begrijpen dat elke storing in de service kan leiden tot een verstoring van uw bedrijf. Als een gebaar van onze inspanning om de hoogste kwaliteit service verlening te bieden heeft Microsoft uw organisatie proactief een service krediet verleend van 25% van uw maandelijkse factuur. Het krediet word automatisch verrekend met een toekomstige factuur, en het is niet nodig hiervoor contact met Microsoft op te nemen. Houd er rekening mee dat de verwerking van het service krediet tot 90 dagen kan duren.

Als u nog meer vragen heeft, aarzelt u dan niet om contact met ons op te nemen. Onze klantenservice is 24 uur per dag zowel telefonisch of via serviceaanvragen afkomstig van het Beheercentrum voor Microsoft Online Services bereikbaar.

Dank u voor het kiezen van Microsoft Online Services voor het hosten van uw zakelijke productiviteitstoepassingen. Wij stellen uw klandizie zeer op prijs.

Met vriendelijke groet,

De Microsoft Online Services-Team
Weer een klap voor de cloud, en er komen er nog meer waardoor bedrijven weer snel de bezemkast ombouwen tot serverruimte (ondanks dat dan je uptime nog lager ligt)

Word eens tijd voor een tweede grote datacenter in Europa van Amazon
tja heel simpel. Bij Amazon moet je zelf het ontwerp van je architectuur doen. Als je op hun cloud afhankelijk wil zijn van 1 datacenter, ipv bijvoorbeeld back-up deel in de VS te doen. Dan kan het zijn dat een datacenter een keer plat gaat.

Beetje jammer dat het dan direct "een klap voor de cloud is". Sites die hierdoor off-line zijn gegaan, zijn hebben dat aan hunzelf te danken, hadden ze maar beter na moeten denken over de architectuur van het platform.
Als je op hun cloud afhankelijk wil zijn van 1 datacenter, ipv bijvoorbeeld back-up deel in de VS te doen.
Een recent onderzoek wees uit dat bedrijven heel huiverig zijn voor 'data in Amerika'. Aangezien dat dan triviaal opeisbaar is. Het gaat toch om je bedrijfsgeheim in een aantal gevallen. (in principe zie ik alles als bedrijfsgeheim).

Nu is dat sinds kort ook geldig voor data die in Ierland staat (omdat Amazon een Amerikaans bedrijf is, en dus altijd - ongeacht de locatie van de data - gehoor moet geven aan zo'n opdracht. Dus dat gaat of zorgen dat mensen bereid zijn om hun data in Amerika te plaatsen (ook), of voor een exodus zal zorgen.
@arjankoole: dat van data in ierland staan ook opgeeist kan worden is nog triviaal, ondanks dat amazon een amerikaans bedrijf is, moeten zij zich houden aan de wetten van het land waarin zij opereren. Dus als de amerikaanse wet zegt dat ongeacht in welk land de data staat, maar het bedrijf amerikaans is, dat de data opgeeist kan worden, maar het land waarin de data staat zegt dat data niet zonder toestemming opgevraagd kan worden, dan hebben ze een probleem.
misschien is dan de keuze voor de Amazon wel verkeerd, maar moet je maar voor een provider met minimaal twee europeese datacenters kiezen :)
Tja - het feit dat een server 'in the cloud' draait betekent natuurlijk niet dat 'ie niet plat kan gaan. Veel mensen gaan er van uit dat omdat de server in een datacenter staat en virtueel is, de uptime bijna 100 % is. Dat is natuurlijk niet zo - dat zul je zelf moeten regelen!

Bij de vorige grote outage van Amazone kwamen veel kleine bedrijfjes in de problemen omdat heel hun business draaide op de EC2 diensten - zonder dat ze zich realiseerden dat het niets anders zijn dan (bijv.) VMware images op gewoon echte servers. En net als bij echte servers moet je als klant zorgen dat er een backup is in geval van problemen - of je koopt dat in bij je provider...
Als je een echte cloud oplossing hebt moet je wel een uptime van 100% kunnen halen. Dit lijkt meer een server farm, en dat is toch wat anders.
Als je een echte cloud oplossing hebt moet je wel een uptime van 100% kunnen halen. Dit lijkt meer een server farm, en dat is toch wat anders.
Zelfs google kan geen 100% garantie afgeven, omdat ieder systeem - naar mate het complexer wordt om al die acties te coordineren - gevoeliger wordt. Zeker als je te maken hebt met datacenter- en land- overschreidende omgevingen.

Daarnaast zijn bedrijven huiverig (bleek onlangs uit een rapport) om spullen in Amerika onder te brengen (en de nieuwe regelgeving dat een Amerikaans bedrijf ook data moet opleveren die niet in Amerika, maar in Europa staat - zoals Amazon met hun Dublin deel van Amazon Cloud - zal nog minder goed doen in dat opzicht), wat een deel van de redundantie mogelijkheden van Amazon of welke cloud ook, onderuit haalt.

Als je echt redundant wil zijn, moet je dat met hele vernuftige setups doen, die gebruik maken van diverse technieken, waaronder op netwerk niveau (met bijvoorbeeld BGP4). Zelfs daar echter, is 100% onmogelijk te garanderen. Ik heb 't wel eens gehaald met zo'n setup, maar dat was uitzonderlijk.
Dan nog kunnen er problemen met dataverlies optreden. Filecaching op OS niveau is dodelijk als je aardig wat transacties per seconde aan het verwerken bent. Er is altijd wel iets aan data wat nog niet op de storage terecht is gekomen als een server hard uit gaat.
Dan heb je het verkeerde OS/DB systeem. Een goede DB flushed de data naar disk voordat de applicatie te horen krijgt dat alles ok is. Dat zijn zaken die je gewoon goed moet regelen/testen als de wens van de klant is om 'veel negens' aan uptime te hebben.
Uptime is ook een kwestie van geluk, ik heb wel eens een server meegemaakt die 3 jaar uptime had. Hier was alleen een UPS op aangesloten maar verder was het systeem totaal niet redundant.
Uptime is wel te sturen, uptime van een server is ook niet het probleem, servers gaan geregeld uit en aan voor updates etc. tijdens dat proces wordt de productie verhuist naar een ander cluster, vervolgens wordt de correcte werking van de server getest alvorens deze weer in productie wordt genomen. In deze situatie had een tweede datacenter de productie over moeten nemen dmv een failover (althans, dat verwacht je van een grote club als Amazon).
Rackspace biedt wel degelijk 100% uptime garantie aan... of ze het halen is een tweede, maar het *aanbieden* kan blijkbaar wel degelijk ;-)

http://www.ispam.nl/archi...ouddienst-met-100-uptime/
Dan moet je het imho ook niet brengen als een echte "Cloud" oplossing, maar als oplossing die ook "Cloud" capabilities heeft.

Nu is het verwachtingspatroon toch anders.
Ik denk dat jou definitie van cloud anders is dan die van Amazon. Op dit moment koop jij van Amazon een virtuele server waar jij geen omkijken naar hebt. Je zou bijna gaan zeggen dat dat niets anders is dan een managed server maar dat is het wel aangezien je hier betaalt naar verbruik en niet naar machines die je hebt staan. Het is allemaal hardware capaciteit on demand die je zelf niet onderhoudt en geen omkijken naar hebt.

Ik vraag mij af waarom het niet vreemd is als een bedrijf 1 server heeft staan in de datacenter en deze onderuit gaat maar zodra dat zelfde bedrijf 1 virtuele server van Amazon heeft en deze gaat onderuit dan is dat ineens raar?

Mensen moeten zich realiseren dat als je voor IAAS gaat dat je je eigen architectuur moet opzetten, als je voor PAAS gaat zal dat (mogelijk) niet nodig zijn.

Edit: -e

[Reactie gewijzigd door zenica op 8 augustus 2011 09:55]

Het kan ook wel, maar dan betaal je natuurlijk wel de hoofdprijs. Een mooi stukje van Smugmug over de vorige Amazon outage:
http://don.blogs.smugmug....ived-the-amazonpocalypse/
Mee eens. Het is ineens hip om een datacenter een cloud te noemen, maar dat is m.i. marketingflauwekul.

In een echte cloud maakt het niet uit waar je data zich fysiek bevindt. Eigenlijk is Amazon's CDN (CloudFront) de enige "echte" clouddienst die ze aanbieden, hoewel daar ook een SPoF in zit (de zgn. origin server).
alles is mogelijk ook 100% maar de vraag is wat kost het en wat wil iemand betalen ?

Waar ik me over verbaas in dit artikel is dat men binnen een paar uur wel weer stroom had maar veel zaken schijnbaar handmatig moesten worden opgestart, waarom handmatig en niet automatisch ?
Dat Amazon een slechte dienstregeling heeft betekent natuurlijk niet dat gelijk alle Cloud diensten in de kern een foutieve gedachten hebben. Kijk maar naar Google en Microsoft, die hebben wel degelijke redundantie over de hele wereld. Als je cloud diensten van een provider afneemt dan doe je er natuurlijk goed aan om even te checken hoe de dienstregeling in elkaar zit. Als het daadwerkelijk een provider is die opereert vanuit een bezemkast dan zou ik niet mijn hele bedrijf er afhankelijk van maken.
Amazon een "slechte dienstregeling"? Wat een onzin! Ze hebben een uitermate goede dienst opgezet, maar als je er geen gebruik van weet te maken, en als je de kosten er niet voor over hebt, dan loop je deze risico's. Ik betwijfel of Microsoft het beter geregeld heeft. En Google biedt niet een vergelijkbare dienst aan.
Wat is cloud nu werkelijk? het enige dat cloud aangeeft is dat je niet precies weet waar je data nu exact staat, maar cloud geeft helemaal niet aan dat het ook een bepaalde uptime garandeert. Als voor jou als bedrijf zo belangrijk is dat je een zo hoog mogelijk uptime hebt, dan moet je dus zorgen dat je ook eigen servers op locatie hebt, want internet is zo makkelijk verstoort.
Enuh, Amazon opereert echt niet vanuit een bezemkast.
Zo zie je maar: een tweede back-up is nooit weg...

[Reactie gewijzigd door Passeridae op 8 augustus 2011 10:39]

Een cloud die down gaat door een real world cloud. Ik zie de ironie wel :Y).

(meer ontopic ;))
Dat er nu geen automatische generatorstart was kan ik wel begrijpen, maar waarom duurt het dan nog vele uren voordat het handmatig weer op orde is? Uren later is pas 75% online. Zijn de systemen dan zo afhankelijk gemaakt van een volledig automatische doorstart, dat een handmatige start niet voldoende getest is?
Dat er nu geen automatische generatorstart was kan ik wel begrijpen, maar waarom duurt het dan nog vele uren voordat het handmatig weer op orde is? Uren later is pas 75% online. Zijn de systemen dan zo afhankelijk gemaakt van een volledig automatische doorstart, dat een handmatige start niet voldoende getest is?
Die systemen zijn niet gemaakt om in één klap allemaal tegelijk opgestart te worden. Ze zijn in beginsel gemaakt om allemaal aan te blijven staan en nooit uit te gaan. Dat hoort die noodstroom ook te regelen, maar alles kan fout gaan en dat is hier gebeurd. Daarbij is dus alles uit gegaan, wat betekent dat je handmatig moet opstarten. Dat betekent dan weer een klap op je stroomvoorziening (dus kun je niet alles écht tegelijk aanzetten), en aangezien volgens mij hun storage ook gecentraliseerd is betekent dat ook een klap op je storage (en dat gebeurt dan wél weer redelijk tegelijk.) Dat soort zaken maakt een handmatige start een langzaam proces.
Dit is pure overmacht, daar kan Amazon heel weinig aan doen.
Een fikse bliksem inslag kan ieder bedrijf treffen, het is de natuur aan het werk en gelukkig kunnen we daar nogsteeds bar weinig aan veranderen.
Een goede UPS kopen is misschien ook een optie. Een UPS moet beschermd worden tegen bliksem inslag. En daar heeft de mensheid surge arresters voor uitgevonden. Deze zijn na een inslag wel stuk, maar ze moeten de apparatuur erachter beveiligen.

Ik krijg niet precies duidelijk welke UPS men daar heeft, maar krijg het gevoel van een batterij UPS. Deze nemen korstondig de energie voorziening over zodat nadat de gensets opgestart zijn deze het over kunnen nemen. Deze konden echter niet synchroniseren naar de fase die door de accu's gemaakt werd.

Een dynamische UPS had dit probleem niet gehad. Bij een bliksem inslag in de net trafo zal de UPS stroom leveren om ervoor te zorgen dat de kortsluiting er zo snel mogelijk uitbrandt. Dit zorgt er echter ook voor dat door de juiste selectiviteit de input breakers trippen op overstroom. Hierdoor is de UPS los van de kortsluiting, los van de utiliteit en doet dan dus precies waarvoor het gemaakt is. Synchronisatie is bij een dynamische UPS namelijk helemaal niet nodig tijdens een net uitval.

Edit: Typo

[Reactie gewijzigd door Timo002 op 8 augustus 2011 11:00]

Het wordt tijd dat ze alle servers op 12VDC aansluiten, dan heb je helemaal geen problemen meer met synchronisatie, 230VAC is nergens voor nodig in een server, alles draait intern op 12 en 5 volt, twee kleine 12 > 5v trafo's in de server, met redundant uitgevoerde centrale 230VAC > 12VDC trafo's is efficiënter dan 2000 losse redundante voedingen in servers, veiliger dan 230V en bovendien makkelijker voor de UPS. De accu's zijn meestal 12V, het hele 12VDC (accu) > 230VAC (omvormer) > 12/5VDC (servervoeding) conversieproces is nergens voor nodig en een waste of energy. Damn, waarom is niemand eerder op dit idee gekomen, een heel huis kan op 12V, op die paar keukenapparaten en een boormachine na ;) Dan wordt die inverter voor zonnepanelen ook overbodig.

[Reactie gewijzigd door donny007 op 8 augustus 2011 11:20]

Leuke gedachte, maar ik ben bang dat je niet weg komt met je vermogens! Datacenters hebben vaak busbar's waarvan af de spanning afgetapt wordt naar de server zalen / koeling etc.

Deze busbars zijn dikke stukken koper waar (afhankelijk van de grote van het datacenter) 10 - 20 - 30 MegaWatt aan energie door heen moet kunnen. Dit is een beetje veel om met 12V te realiseren. Dat gaat je helaas niet lukken.

Denk ook aan kortsluitingen die op kunnen treden. Daarvoor zijn immense stromen nodig om die weg te branden. Hier heb ik het niet over 100 Ampère, maar over 30 - 80 kA (80.000 Ampère). Dit staat wel kortstondig, maar accu's kunnen dat niet leveren. De generator van een dynamische UPS kan dat echter wel.

Edit:
Vaak wordt er trouwens op midden spanning gewerkt om dergelijke grote vermogens te kunnen leveren. Simpelweg omdat dit met laagspanning niet meer lukt.

Een andere oplossing is een kleine UPS in de server zelf. Probleem blijft echter dat op welke manier je ook met accu's werkt, ze op raken. En dat binnen korte tijd. Als backup heb je dus altijd gensets nodig om langdurige spannings uitval op te vangen.

Stroomstoring is volgens mij ook geen goede benaming voor dit probleem. Het is namelijk een spannings uitval. Zonder spanning geen stroom. Zonder stroom nog steeds spanning. De stroom kun je niet regelen, de spanning wel. De spanning valt dus weg waardoor je een stroomstoring krijgt.

[Reactie gewijzigd door Timo002 op 8 augustus 2011 11:49]

Veel servers en routers kunnen op -48V DC draaien en dat gebeurd ook vaak in datacenters voor telecom toepassingen en ISPs.

Dus het kan wel al moet de vertaling naar 12V (5V, 3V, 1,5V, enz.) dan nog steeds in het rack zelf gebeuren.

Accu batterijen kunnen enorm hoge kortsluitstromen halen, ik dacht juist veel hoger dan generatoren en transformatoren.
Accu batterijen kunnen enorm hoge kortsluitstromen halen, ik dacht juist veel hoger dan generatoren en transformatoren.
nee, precies andersom.
Voordelen van roterende UPS ten opzichte van statisch. Oke, misschien wij van WC eend. Maar het is wel waar.

Deze wiki heeft het zelfs over 17x hogere kortsluit stromen dan een accu no break.
Geographische redundantie?
Bliksemafleider? Of is dat niet web2.0
Zo zie je maar weer hoe fragiel een infrastructuur is, één blikseminslag en de complete stroomtoevoer (incl. backup-systemen) gaat plat. Wie had ooit gedacht dat je transformatorhuisjes en 'het controlesysteem van de stroomphases' ook redundant uit moet voeren.....
Daar zijn gewoon specificaties voor. Datacenters met 1 stroomtoevoer krijgen een lagere kwalificatie dan datacenters die 2 volledig gescheiden stroomnetwerken hebben (of zelfs twee verschillende leveranciers).
Ik vraag me ten sterkste af of dit uberhaubt mogelijk is hetgeen wat je hier omschrijft. Grote stroomverbruikers zoals deze krijgen via Enexis een eigen transformator, deze heeft echter wel weer 1 voeding. Ik heb het zelf nog nooit geprobeert en ik kan me goed voorstellen dat dit bij Enexis een lastige kwestie is maar stel, het is mogelijk om een 2e transformator aan te vragen wordt deze nog steeds gevoed uit hetzelfde netwerk. Links of rechtsom als de uiteindelijke voeding uit het netwerk wegvalt valt het simpelweg weg. Twee verschillende leveranciers is simpelweg niet mogelijk overigens aangezien de netwerkbeheerder de enigste is in zijn gebied (ondanks dat deze is vrijgesteld is in de Europese markt). Dit heeft meer te maken met het feit dat netwerk aanbieders simpelweg landen opgeknipt hebben en geen overlap kennen.
Sommige grote datacenters (en andere grote bedrijven die van elektriciteit afhankelijk zijn, zoals hoogovens) halen dus wel elektriciteit uit 2 verschillende "netwerken". Een dure grap uiteraard, aangezien daarvoor meestal (tenzij je bots op de scheidingslijn tussen 2 onafhankelijk werkende netwerken zit misschien) een speciale lijn uit een ander stuk elektriciteitsnet naar dat bedrijf getrokken moet worden...
Los van het terechte punt dat je maakt. Hoogovens kunnen hun eigen energie opwekken. Dit leveren zij meestal aan het net, maar als er een storing is kunnen ze zichzelf hiermee van energie voorzien.
Of zo zie je maar weer hoe veel impact bliksem kan hebben. Zelfs met een bliksemafleider ben je niet 100% beschermt.
Amazon's EC2-dienst werd geveld door een onweerswolk... Dus als ik het goed begrijp: cloud tegen cloud? :+
Amazon adviseert overigens om een failover in te richten in een datacenter in een andere geografische regio om downtime als gevolg van een storing in een andere regio te beperken, al betekent dit voor veel bedrijven wel een forse stijging van de kosten.
Ja, duh. Veel bedrijven denken aan de cloud als kostenbesparende oplossing, terwijl het dacht ik nooit als zodanig is neergezet. Als je redundantie in de cloud wil, prima, maar dat betekent gewoon geografische spreiding. Amazon kan dat best leveren, maar dat gaat je geld kosten. Als je zo cheap bent om maar op 1 locatie je spul te hosten, prima, maar ik snap dat Amazon in zo'n geval er goed aan doet om zich daartegen in te dekken.

De failover-procedures die er zijn, zijn er ook voor de klanten, niet alleen voor Amazon.

[Reactie gewijzigd door 19339 op 8 augustus 2011 08:45]

Het blijft een kostenbesparende oplossing, want als een klant zelf zijn datacenters redundant op verschillende locaties wil exploiteren dan kist dat veel meer dan dat dmv. een cloud oplossing te doen.

Wat had je gedacht van een overstroming, bitter weinig bedrijven in Nederland hebben daar daadwerkelijk rekening mee gehouden qua backup datacenter.
Hangt er maar helemaal vanaf wat en hoe efficient je met je servers om gaat.
Cloud diensten zijn helemaal niet gratis en sommige diensten van Amazon zijn behoorlijk aan de prijzige kant om maar niet te spreken over het gebrek aan support.
Als kleine klant kan je een dikke middelvinger krijgen en vaak krijg je al helemaal geen reactie op support issues.
Doet me denken aan deze AWS forumpost bij de vorige outage (die in april): https://forums.aws.amazon...D=65649&start=25&tstart=0

(Perfect voorbeeld van het nooit blind vertrouwen op je provider)
Het is gewoon dom om zulke informatie in de cloud op te staan. Internet is nooit 100% betrouwbaar en dat zal het ook nooit worden. Er is een post die het perfect zegt:
"Amazon sets service level expectations at 99.95% availability. What is your plan for the expected 0.05%, not to mention the unexpected?"

Amazon beweert ook niet dat ze 100% uptime hebben en dat KUNNEN ze gewoon niet garanderen.
Sterker nog;

amazon zegt dat je zelf zorg moet dragen voor redundantie en failover. Heel logisch ook. Dus je moet zelf zorgen dat je in een ander datacenter een fall-back omgeving ingericht hebt. Ookal is dat in een 2e datacenter van Amazon.
Niet alleen Amazon had last van deze stroomstoring. Microsoft host zijn BPOS (Exchange in de cloud) waarschijnlijkj in hetzelfde datacenter. Deze dienst was om middernacht ook onbereikbaar (oorzaak power outage in Dublin) en om 2.30u was het service hersteld.
Klopt, hier had ik ook al last van. Mijn eerste mails kwamen rond 00:30u weer binnen. Vond het al zo raar dat alle services plat lagen, overal stond een rood kruisje bij het health center.
Al je belangrijke business draait in de cloud ben je ook niet erg slim bezig als je geen fail-over inricht in een andere locatie. Of het nou cloud servers, virtuele, of fysieke systemen daar ben je zelf verantwoordelijk voor. Heeft niks met gevaar van de cloud te maken maar puur met het gevaar van alles runnen van uit 1 fysieke locatie.
Het is een kwestie van kosten-baten. Wij draaien alles vanuit Dublin, maar zorgen wel voor backups van snapshots waar we altijd bij kunnen. Het kan dus gebeuren dat we een dag offline zijn. Als dat te vaak gebeurt, dan zullen we ook wel overstappen op twee locaties, maar dat is nu nog niet aan de orde denk ik, gewoon omdat het te duur is.
Misschien hadden ze beter transformators in de kelder of zoiets moeten plaatsen zodat het blikem daar niet kan bereiken... Dat zou ik wel doen als we in een wereld vol met bliksems leven.
Kelders zijn weer minder handig als je met lekkage of overstromingen te maken hebt. Dan staat al je HV-spul in een put met water, en ben je helemaal afhankelijk van electriciteit om de boel droog te krijgen/houden.

Maar dan nog: maakt het uit waar je de transformator neerzet? Een surge kan prima via de kabels binnenkomen, dan maakt het niet uit waar het spul staat.

Sterker nog, als een transformator kan ontploffen (ik weet dat er olie in kan zitten), is de laatste plaats waar ik het wil hebben wel onderin een datacenter.

[Reactie gewijzigd door 19339 op 8 augustus 2011 11:11]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True