Server struktur

Har du frågat andra elever och även läraren? Vad gav dom för input i så fall?
Än har du bara skrivit din syn på det.

Best practice brukar väl ändå anses vara att domänkontrollanter bara sköter den rollen och DNS. Det efterlevs väl sådär på det flesta håll, det är ganska vanligt att man kör IIS eller file services på maskinen också. Jag sätter alltid upp mina med bara AD och DNS.

Nu är det ju inte varje dag jag sätter upp en miljö sådär eftersom jag inte konsultar så mycket numera utan är på ett och samma ställe hela tiden. Ska jag sätta upp en labb/test-miljö eller liknande brukar jag låta den fysiska maskinen köra enbart Hyper-V och sedan sprida ut rollerna på varsin VM.
Grundtänket för min del är alltid AD/DNS på separat maskin (eller ännu hellre flera, jag tycker AD mår bäst av att köras på flera burkar). Resten av rollerna kan man sprida lite som man vill. Jag har fördelen av att ha volymlicensiering, så antal licenser är inget hinder. Det är gissningsvis inga problem att köra någon av RD-rollerna på sin DC, jag tycker mest att det blir lättare att felsöka om AD har sin egen maskin att leka med...

Så lite så, förväntade mig nästan att få mothugg av någon som har egna idéer - man brukar få det här på Swec

1) Virtuell host på en fysiskt maskin och inget mer på denna maskin, inget aldrig någonsin . Den är en hypervisor och inget mer. Absolut aldrig.
2) Var sak på varsin maskin (virtuell eller fysisk är en annan diskussion). Givetvis får man kompromissa ibland men best practice är att ha en roll per maskin.
3) DC på en dedikerad maskin med DNS.
4) Två domänkontrollanter varav helst en på en fysisk maskin är best practice fortfarande så långt jag vet. (Råder dock delade meningar om hurvida en fysisk maskin är nödvändig eller ej, vettigt att läsa på i detta ämnet.) Men att du ska ha minimum två är nödvändigt och inget man bör kompromissa på. Ska absolut inte dela maskin med andra roller.
5) IIS, aldrig dela den med andra tjänster som inte kräver det, ur säkerhetssynpunkt men även prestanda.
6) Terminalserver och dela maskin med DC?! Nej absolut aldrig. En terminalserver ska alltid vara en dedikerad maskin likt en IIS. Detsamma gäller för Remote access i andra former.

Den viktigaste punkten som man absolut aldrig någonsin under några som helst omständigheter ska kompromissa på är punkt ett, en hypervisor ska aldrig någonsin göra något annat då förlorar den helt sin roll. Samma sak gäller med DC men kanske inte riktigt på samma extrema nivå.

Men varför?
Jag kan håla med om det i teorin men varför i praktiken?
vikeln storlek på företag? SMB-server? vilken version av OS?
Är det 100+ inget snack men i småföretag hade jag sagt kumpa ihop skiten och hoppas på det bästa!
Jag har dedikerade DC (GC) på fysiaka serverar hos oss men allt annat virutaliserat, men i själva verket är DC/GC jobbet en fis-i-sjön gentemot allt annat servrarna gör, en exchange server är så tight integrerad att jag ser det som en fördel att ha den på samma server i en liten miljö.
med 2012 är det en viss fördel att ha flre servar, men igen varför, och vilken storlek på företag?
Ju färre användare ju mindre antal servrar skulla jag vilja säga! Fler användare, fler servar för att minimera "impact" mot slutanvändare, i grundutförandet ser jag inga problem att köra rubbet på samma server!
vissta är det potenshöjande att köra flera servrar, gärna virtualiserade på ESX och ett fete SAN med "all flash", men varför?

// bC

Om man inte är tillräckligt stor för att göra det rätt är det billigare och bättre att köpa tjänsterna.
Ju fler system desto fler servrar, grunduppsättningen har inget med antalet användare att göra.

Dessutom behöver du absolut inga feta servrar eller feta lagringslösningar för att bygga en vettig virtuell miljö, det som kostar en slant extra för att göra rätt är licenser för server vilket många skyller på. Men med tanke på att man köpa en 2012 Standard för ca 5000kr så kostar med andra varje virtuell server du vill köra upp till 2500 kr i OS licens vilket får anses som en liten kostnad. Anser man inte att systemet man ska köra på den är värt 2500kr så tycker jag man ska överväga att inte köra det alls.

Jag som trodde det, allt som oftast, var i CAL-licenserna som kostnaden låg i...
Men börjar du sprida ut tjänster på fler servrar, så kommer du fortare fram till punkten då kostnaden för SAN/Nätverk och servrar springer iväg i kostnad.
Samt då även kostnaden för admin verktygen (oavsett ESX eller Hyper-V). Så till en viss gräns på företag är det vettigare att hålla ihop tjänsterna på så få servrar som möjligt. Att köpa in en liten miljö på azure kan ju verka billigt och enkelt, men räkna ihop en ny A1 server för varje tjänst och sen koppla ihop det med en SQL, en webplats och det är ganska dyrt...
Då är inga kostander för backup/överföring/bearbetning etc tagen.

Så jo storlek på företag (och typ av företag) är intressant skulle jag vilja säga, innan jag tvärsäkert säger sprid ut alla tjänster.

// bC

Instämmer med föregående talare, separera allting så gott det går och behandla grundpartitionen (Hyper-V hosten) som att den endast är en hypervisor. Även brandväggen tycker jag att du kan göra virtuell, antingen genom en maskin med RRAS eller en enkel pfSense (föredrar det personligen på grund av enkelheten och de låga systemkraven).

Om det är något som jag ska klaga på så är det användandet av WS2008R2. Det finns två senare versioner där det kommit många förbättringar. Ska man lära sig något så kan man lika gärna lära sig det senaste. Finns mycket nytt i framförallt Hyper-V i WS2012R2

anledningen till att alla tjatar om att inte använda Hosten till mer än Hyper-V är att den kommer ALLTID ha mer prioritet när det gäller resurser.
Tänkte att jag skulle klargöra det.

If it aint broken dont touch it.
Det där ordspråket tillämpas allt för ofta.

Det är oftast i åtkomstlicenser som kostnaden ligger, vet inte hur du tolkade mitt inlägg som att det inte var det? Har inte ens diskuterat åtkomstlicenser då det är helt irrelevant för virtuellt eller ej.

Utveckla gärna din punkt med kostnad ifall man väljer att sprida fem tjänster på fem virtuella maskiner vs att köra dom på en och samma fysisk och varför ett litet företag ska köra allt på samma maskin medans ett stort inte ska det. Kostnad för hårdvara menar jag då, att licenskostnaden för operativsystem ökar något vet vi.

Om inte arbetstiden/arbetskostnaden sätts till noll i kalkylen så kostar fler servrar mer pengar oavsett fysiska eller virtuella,
tänker man inte efter före så riskerar man att bara lägga till ett lager av komplexitet som inte tillför något mer än arbetstid.
Ett mindre företag har inte samma skalfördelar som ett större företag,
att ha en dedikerad IIS för ett intranät på fåmansföretag är oftast bara lyx,
är det den publika siten så kan jag gå med på det utan problem, men inte annars utan bra skäl...

På ett större företag separerar man tjänsterna för där prioriteras upptid mer,
att ta ner hela miljön (om det ligger på en server) för att installera en patch för "whatever" är inte acceptabelt.
ekonomiavdelningen har ingen förståelse för att HRavdelningen behöver patcha sitt system, där av separerar man, gemensamma system klustrar man, en SQL-server med always-on exempelvis så den behöver aldrig tas ner.
Har du ett fåmansföretag kostar det mer i underhåll och drift än att låta 1-10 stackare sitta och vänta, om du behöver göra en akut omstart.
Jobbar man så reaktivt att man behöver göra akut omstarter så ofta är man kanske inte rätt man på rätt tjänst...
Och är det exempelvis ADt som har pajjat spelar det ju ingen roll om du har din IIS uppe för den är ändå med stor sannolikhet AD integrerad och viceversa...
(detsamma gäller IIS<>SQL | SQL<>HR-system, har en del gått ner spelar det ingen roll så man kan lika gäran starta om allt ändå, lite raljerande men du fattar)
Gör du det för upptid så behöver du minst två fysiska servrar och minst två "storage", då både SAN och hypervisors behöver patchas...
Vill du inte sitta med Storage vMotion dagarna i ända är det enda sättet om du inte skall ta ner hela miljön.
blandar du in SAN kräver dom mer och bättre bandbredd då det även är replikerin SAN<>SAN och inte bara trafik mellan host<>SAN vilket ger dyrare switchar.
och hela cirkusen är igång, så min erfarenhet är att hålla allt så kompakt och enkelt som möjligt och sen när det inte är hållbart längre bryta loss tjänsterna en efter en, har man planerat allt rätt, innan, är det inga problem.
Har man allt pekandes till samma server, gärna med ip-nummer, sitter man i skiten, så så länge du vet vad du gör är det enklare med en server.

När jag jobbade som konsult var det alltid mycket enklare när "bosses svets och chark" ringde om problem,
att säga "starta om servern", om den inte svarade alls, än att säga "logga in på vCenter, klicka dig fram till "host and clusters", gå till STHLM-SQL023-1, kör restart, fungerar inte det så är det i IISen problemet ligger öppna då STHLM-WEB-011-1 och..."

Så jag är inte rabiat och tycker att allt skall vara samlat hela tiden men det finns gränser för varje företag hur mycket man kan och bör virtualiesra och hur mycket man skall sprida tjänster. har man dedikerad personal som vet vad dom håller på med så skala ut, ju mer ju bättre, innan dess håll ihop det kommer bara kosta mer i hårdvara och drift.

Jag tycker att du ser på frågan från helt fel håll och gör det misstag jag har sett hos många mindre kunder.

Vilket är naturligt eftersom konsultbolag som erbjuder på platsen installationer/felsökning/support/försäljning vill att kunden själv ska drifta sina system såvida dom själva inte tillhandahåller en on-demand lösning. Samtidigt som man är rädd för att ge kunden kostnaden det kostar att sätta upp en vettig miljö och inser att om man gör det väljer dom en on-demand lösning istället... Så då kompromissar man...

Du tar själv ett intranät på ett fåmansbolag som exempel, att där kan man inte sätta upp en dedikerad maskin för detta? Varför i hela friden skulle detta fåmansbolag från börjar drifta sin IIS själva? Köp ett 9kr webbhotellspaket om inte tjänsten är så viktig så har du sparat kunden en massa pengar i drift/inköp och underhåll.

Bara för att vi talar om att virtualisera behöver inte det innebära att man ska köpa in redundanta lösningar för lagring och ett cluster med massor noder. En hypervisor som kör en näve virtuella maskiner utan extern storage ger fördelarna att du KAN skala ditt system. Inte att du nödvändigt måste göra det.
Sedan att man får klicka på "Installera uppdatering" på 5 maskiner istället för en ger ju ett visst merarbete, det kan jag gå med på.

Sedan kan man inte fakturera xxxxx kr för att migrera ut kundens växande HR system den dagen det behövs, men det är ju snarare er förlust och inte kundens.

OBS: Läs mina syrliga kommentarer som exempel och inte ett anklagande mot ert/ditt agerande mot kunder

ingen fara, jag tar inte åt mig. Har inte jobbat som konsult på nästan ett decennium nu och har branschen förändrats som du beskriver den kommer jag nog inte återvända... men som tur är så är mina erfarenheter att alla konsultbolag älskar azure då det ger mer konsult timmar, så jag läser kommentarerna mer som bittra inlägg... Jag vet inte vilka intranät du kommit i kontakt med men jag har aldrig träffat på någon som på fullaste allvar skulle lägga den informationen på ett 9 kronors webbhotell för att spara pengar...

Det tar i praktiken en koppkaffe att klona upp en maskin på en ESX (och ja, lika kort tid på en hyper-V, dom andra motorerna jobbar jag inte med men jag misstänker att hastigheten är densamma) mot hyggliga disksystem (interna eller externa).
Så att göra "rätt" från din horisont på en "felaktig" installation tar kortare tid än besparingen skulle bli. Att bryta loss alla tjänster på en SBS (eller annan server med hög "tjänst densitet" eller vad man skall kalla det.) till fristående tjänster är max en dags arbete även om setupen är kass från början så, från mitt "felaktiga" sätt att se på saken, håll ihop tjänsterna det blir lättare att underhålla tills man kommer till en viss punkt min erfarenhet säger att den i de allra flesta fallen är beroende på antalet användare som kan drabbas (tillgänglighet på tjänsterna), i exemplet trådskaparen hade, hade jag valt att köra AD på den fysiska maskinen så att DC/GC tjänsterna startar upp först så autentiseringsbiten funkar så snabbt som möjligt, även om en virtuell dator startar runt 10ggr snabbare än en fysisk.
Återigen att bryta loss en IIS-site från en SQL-serverinstans skall inte behöva ta mer tid än det tar att kopiera över databasfilerna (ok om siten inte kör med lokala SQL användare tar det lite extra tid men högst några minuter), så det finns inget argument att göra "rätt" från början genom att separera tjänsterna, för det går tok fort att korrigera småsystem.
Ta ett HR-system, uppdateringsfunktionerna på dom gör att det allt som oftast tar ett bra tag att genomföra (vilka man ändå måste göra för att uppdatera fackavtal, skattesatser, lagkrav, etc) på den dö tiden kan man med lätthet klämma in en virtualisering/utskalning av ett sånt system under vanlig serviceunderhållstid.

// bC

Som enkelt svar på ursprungsfrågan så lägg DC+DNS på extern samt virtuell. Funkar utmärkt med dessa funktioner på samma maskin.

Anledningen är att om den virtuella miljön inte startar så funkar annars inte funktioner som kräver säkerhetsverifiering (typ att logga in).

Att ha två stycken servrar med DC+DNS är helt enkelt för att ett MS-nät är rätt så dött utan dem.