mboost-dp1
Serverflytning
Vi har i dag flyttet sitet til nye servere. Det gav desværre lidt problemer undervejs, men alt skulle være på plads nu.
newz flyttede til Azure for over et år siden.Hubert (5) skrev:Jeg troede ikke der var andet end Microsoft konsulent huse der brugte azure.
Og der er skam mange der bruger det i DK, store som små virksomheder/offentlige instanser.
Microsoft matcher som minimum Amazons priser så det er næppe der. Stabilitet kunne det være, selvom det ikke virker til newz har været ramt så hårdt.Hubert (5) skrev:Pris. Stabilitet eller mangel på samme kunne være bud på hvorfor man vælger azure fra.
Magten (6) skrev:newz flyttede til Azure for over et år siden.
Og der er skam mange der bruger det i DK, store som små virksomheder/offentlige instanser.
Ingen af de kunder jeg kommer hos bruger azura. Og her taler vi både meget store private virksomheder og større offentlige kunder. Nogle af dem har endda en [sic] microsoft politik...
Microsoft matcher som minimum Amazons priser så det er næppe der. Stabilitet kunne det være, selvom det ikke virker til newz har været ramt så hårdt.
Jeg kender intet til priserne. Det var blot et potentielt bud.
Jeg har adgang til en shell på en linux host der kører på azure. Jeg kan ikke just påstå at jeg er imponeret. Jeg oplever relativt ofte udfald hvor min host har mistet forbindelsen til de servere den er koblet op imod. Ting jeg ikke ser på de maskiner vi har i aws.
En kombination af pris, stabilitet og features som alle er langt bedre hos aws
Da vi kører lamp er funktionaliteten hos aws meget tættere på det vi har brug for, hvor funktionaliteten hos azure er MEGET windows agtig hvilket har gjort det relativt bøvlet at køre setuppet der.
Da vi kører lamp er funktionaliteten hos aws meget tættere på det vi har brug for, hvor funktionaliteten hos azure er MEGET windows agtig hvilket har gjort det relativt bøvlet at køre setuppet der.
Jeg sagde heller ikke alle :)Hubert (10) skrev:Ingen af de kunder jeg kommer hos bruger azura. Og her taler vi både meget store private virksomheder og større offentlige kunder. Nogle af dem har endda en [sic] microsoft politik...
Jeg overvåger pt ~40 servere i Azure. Det er yderst sjældent der er udfald på dem - vi har dog været hårdt ramt af 2 nedbrud, hvilket har været pisse irriterende. Det ene kunne vi have designet os ud af ved at benytte flere lokationer, det andet var et storage problem for lidt over en måned siden som ramte globalt.Hubert (10) skrev:Jeg har adgang til en shell på en linux host der kører på azure. Jeg kan ikke just påstå at jeg er imponeret. Jeg oplever relativt ofte udfald hvor min host har mistet forbindelsen til de servere den er koblet op imod. Ting jeg ikke ser på de maskiner vi har i aws.
Jeg har dog oplevet at vores VPN forbindelse kan have nogle bitte korte udfald på 2-3s. Men om det er i vores eller Microsofts ende skal jeg ikke kunne sige.
Kan du gå mere i dybden om features og bøvl?hmn (11) skrev:En kombination af pris, stabilitet og features som alle er langt bedre hos aws
Da vi kører lamp er funktionaliteten hos aws meget tættere på det vi har brug for, hvor funktionaliteten hos azure er MEGET windows agtig hvilket har gjort det relativt bøvlet at køre setuppet der.
Ikke at jeg ikke tror på det, der er mange ting der er/har været bøvlet i Azure. Det er bare interessant at høre hvad der har fået jer til at skifte.
Magten (13) skrev:Kan du gå mere i dybden om features og bøvl?
Ikke at jeg ikke tror på det, der er mange ting der er/har været bøvlet i Azure. Det er bare interessant at høre hvad der har fået jer til at skifte.
Deres cdn er feature mæssigt ubrugeligt med mindre man skiver alt om til at bruge azures eget blob storage lag, og det er slet ikke på højde med kvaliteten i cloudfront
Netværkslaget er nærmest umuligt at arbejde med på linux, og man har stort set ingen fleksibilitet, f.eks. er deres load balancere helt utroligt begrænsede
Muligheden for at ændre ting på netværk, vm's m.m. er enten ikke muligt og man skal sætte alt op forfra, eller også er det med utrolig dårlige command line tools som f.eks. ikke altid virker på mac, eller også kræver de windows
Alle services der ligger "over" vm laget er windows specifikke, så når jeg har brug for memcache, mysql m.m. så er det bare ikke noget ms har da de jo altid vil vælge deres egen inhouse løsning
Hvis ikke man har alt i load balancerede availability zoner og dubleret i hver zone, så bliver ens maskiner genstartet uhæmmet i deres service vinduer, og man kan ikke selv styre hvornår der sker, så man får f.eks. at vide at ens maskiner bliver genstartet mellem fredag kl 10 og søndag kl 22 og så må man bare håbe det ikke skete på et ubelejligt tidspunkt
I det hele taget føles linux supporten meget som noget de har så deres ms kunder også kan have et par linux servere kørende hvis de har brug for det
Jeg har personligt arbejdet med aws i 3-4 år på mit arbejde, og har derfor meget større erfaring med aws, så det har selvfølgelig også indflydelse på valget.
Det var vist lige de mest presserende grunde :) det er muligt at noget af det er blevet bedre hos azure, og når de kører har de da også været ret stabile, men det er tydeligt de er der for deres ms kunder og open source miljøet føler man ikke rigtigt de kigger efter
#14
Jeg takker for svaret, altid interessant at høre om! :)
Jeg kører ikke selv det store Linux i Azure, så jeg kan ikke være med på hvordan supporten er dertil. Jeg ved dog at omkring 20% af VM'erne i Azure (IaaS) er Linux, og uden at kende det totalle antal VM'er så gætter jeg på det ikke er småpenge de omsætter for der. Hvis de leverer en skidt oplevelse så er det også skidt for forretningen når det er så stor en del af den.
De fleste Linux images (LAMP f.eks.) er dog community-drevet.. Det kunne de godt lægge flere kræfter i.
De service vinduer vi bliver informeret om er så vidt jeg husker af 8 timers varighed, sammenhægende mellem fredag kl 18 og søndag kl 22. Det ville ganske være rigtigt være rart at kunne bestemme rækkefølgen de bliver genstartet på - det kan man dog scripte sig ud af. Hvordan håndterer de service vinduer hos AWS?
Men hey, når det er AWS du har styr på, så giver det da også klart bedst mening at have dem liggende der :)
Jeg takker for svaret, altid interessant at høre om! :)
Jeg kører ikke selv det store Linux i Azure, så jeg kan ikke være med på hvordan supporten er dertil. Jeg ved dog at omkring 20% af VM'erne i Azure (IaaS) er Linux, og uden at kende det totalle antal VM'er så gætter jeg på det ikke er småpenge de omsætter for der. Hvis de leverer en skidt oplevelse så er det også skidt for forretningen når det er så stor en del af den.
De fleste Linux images (LAMP f.eks.) er dog community-drevet.. Det kunne de godt lægge flere kræfter i.
De service vinduer vi bliver informeret om er så vidt jeg husker af 8 timers varighed, sammenhægende mellem fredag kl 18 og søndag kl 22. Det ville ganske være rigtigt være rart at kunne bestemme rækkefølgen de bliver genstartet på - det kan man dog scripte sig ud af. Hvordan håndterer de service vinduer hos AWS?
Men hey, når det er AWS du har styr på, så giver det da også klart bedst mening at have dem liggende der :)
Magten (15) skrev:Jeg ved dog at omkring 20% af VM'erne i Azure (IaaS) er Linux, og uden at kende det totalle antal VM'er så gætter jeg på det ikke er småpenge de omsætter for der. Hvis de leverer en skidt oplevelse så er det også skidt for forretningen når det er så stor en del af den.
1.5 B$ om året
lad os antage at 40% er IaaS omsætning og at de 20% af VM kun er 10% af omsætning p.g.a. at det er billigere VM's.
1500 M$ x 40% x 10% = 60 M$ om året
Det er mange peneg for dig og mig. Men for MS er det pebernødder.
De 40% og 10% er rene gæt, men det er næppe 90% og 20%.
Det skal siges at til sammenligning så er service vindue systemet hos aws meget mere elegant, man får at vide at en underliggende host skal udfases, så ens maskine vil blive genstartet på et fastsat tidspunkt ude i fremtiden (mener det er 2 uger ude) og hvis man inden da selv genstarter maskinen så har man selv løst service vinduet og man bliver smidt på en ny host
hos azure er det hele totalt windows, med at de har service vinduer hvor de genstarter hele regioner, hvilket for mig som linux mand er totalt tosset
hos azure er det hele totalt windows, med at de har service vinduer hvor de genstarter hele regioner, hvilket for mig som linux mand er totalt tosset
Det lyder noget smartere ja.
Omvendt så må de have en del hosts som ikke bliver udnyttet særlig effektivt i den periode de står og venter på genstart - det er jo ikke så hensigtsmæssigt, for dem altså.
I Azure rebooter hosten på et opdateret image indenfor de 8 timer man er blevet varslet. Det gøres ikke for hele regioner på en gang, men for det de kalder upgrade domains (en gruppe racks f.eks). På den måde kan man angive availability sets (2 eller flere VM's) som bliver placeret i hver sit upgrade domain.
Jeg kan dog bedre lide ideen om at jeg selv er herre over hvornår mine servere genstarter.
Omvendt så må de have en del hosts som ikke bliver udnyttet særlig effektivt i den periode de står og venter på genstart - det er jo ikke så hensigtsmæssigt, for dem altså.
I Azure rebooter hosten på et opdateret image indenfor de 8 timer man er blevet varslet. Det gøres ikke for hele regioner på en gang, men for det de kalder upgrade domains (en gruppe racks f.eks). På den måde kan man angive availability sets (2 eller flere VM's) som bliver placeret i hver sit upgrade domain.
Jeg kan dog bedre lide ideen om at jeg selv er herre over hvornår mine servere genstarter.
AWS ved jeg ikke, men Azure har ikke live migration.freesoft (20) skrev:Måske dumt spørgsmål, men det undre mig lidt, er der ikke noget ala vMotion på Azure eller AWS?
Af samme grund kan man kun opnå 99,95% SLA'en ved at have to instances af samme VM i et availability set. "Scale-out, then up" er god at have med i designfasen.
Jeg har undret mig over det også. Det eneste jeg har kunne finde frem til er at det ville være et kæmpe arbejde i forhold til netværk og storage når man er oppe i den skala.freesoft (23) skrev:Så kunne man spørge hvorfor ikke? Det er da endnu en fordel vi selv har ved at hoste vores servere.
Magten (24) skrev:Jeg har undret mig over det også. Det eneste jeg har kunne finde frem til er at det ville være et kæmpe arbejde i forhold til netværk og storage når man er oppe i den skala.
Amazon har løst problemet og hyper-v har da så vidt jeg ved support for live migrering. Men det kan selvfølgelig være en begrænsning i måden man har valg, at implementere det i hyper-v, der giver skaleringsproblemer.
Hvis Amazon virkelig har live migration forstår jeg ikke at man skal gøre som #18 skriver.Hubert (25) skrev:Amazon har løst problemet og hyper-v har da så vidt jeg ved support for live migrering. Men det kan selvfølgelig være en begrænsning i måden man har valg, at implementere det i hyper-v, der giver skaleringsproblemer.
Edit: https://gigaom.com/2014/09/29/amazon-and-rackspace...
Det er ikke Hyper-V der er begrænsningen i Azure men storage og netværk som jeg skrev. Hyper-V kan live migrere med intet andet end netværk imellem hosts.
VM'er i Azure har en temp disk som er placeret lokalt på hosten. Hvis man skulle live migrere VM'en væk fra den host ville man potentielt skulle flytte >100GB (per VM). Det tager tid og belaster netværket.
Jeg ved ikke om det er grunden til de ikke gør det, det er bare en teori jeg har.
Og det er i øvrigt nok kun en lille del af grunden.Magten (26) skrev:Jeg ved ikke om det er grunden til de ikke gør det, det er bare en teori jeg har.
Uden at lave en wall-of-text så var Azure fra starten designet som en PaaS løsning. Microsoft kunne derfor bygge failover ind i laget mellem hosten og f.eks. website hosting ved at lave en IIS farm med servere placeret på forskellige hosts. Så ville kunderne ikke opdage hvis en host genstartede. Det er bare ikke muligt i IaaS løsningen da der kun er hosten under VM'en.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- newz.dk
Gå til bund