Requisiti Hyper-V, partizione del disco

La mia regola di command per un server fisico era il disco di accesso random veloce (VelociRaptor / SSD) per OS e grandi dischi per i dati (ad es. WD Caviar).

Come si cerca un Hyper-V che dovrebbe eseguire due macchine virtuali (File Server + Intranet, Dynamics CRM)?

  • Ha ancora senso mettere l'OS fisico su un disco separato?
  • Quanto spazio su disco / RAM devo separare dall'OS fisico?
  • File Server: C'è una notevole differenza di un disco passato vs VHD? Qualsiasi preferenza per uno o l'altro per quanto riguarda il backup, Volume Shadow Copy Service, altre cose?
  • Dovrei dividere le parti del sistema virtuale (FileServer-OS, FileServer-Data, CRM) su dischi fisici separati? Diciamo, con mirror 2x2x1TB o 2x2TB?
  • Come si fa a sostenere una VHD di 'vita'? "come al solito" dall'interno del server?

Ho letto le domande correlate ei requisiti di sistema dichiarati da microsft, sono più alla ricerca di un input pratico, da parte di persone che l'hanno già fatto prima.


[modifica] Le specifiche sono ancora aperte, sto puntando ad un i7-920 quad core, bordo es. Gigabyte EX58-UD5 (aperto a suggerimenti) 8 GB di RAM

Sto puntando ad un totale disco di circa 2TB.

Idea 1: 80GB SSD per Hyper-V, 2 x 2TB WD RE4-GP nello specchio per i due VM, totali a circa 850 €

Idea 2: 4x1TB WD RE-GP in 2 specchi, con conseguente memorizzazione 2x1TB, una coppia per HyperV e prima macchina, l'altra per la seconda. Totale a € 520, consentirebbe un altro 4 GB di RAM che potrebbe fare una grande differenza.

[modifica] Un commentatore ha chiesto la configuration finale, ecco quello che ho imparato (e quello che abbiamo fatto)

Ho deciso contro un attacco hardware, a causa di cattive esperienze con vari controller, la bassa overhead di uno specchio software e la semplicità del trasferimento ad un'altra macchina.

Abbiamo messo la condivisione di networking più occupata per passare attraverso i dischi. Sono "offline" nell'host HV e rispecchiano nella macchina virtuale. La prestazione è adeguata ai nostri scopi.

Ho aggiunto un disco OS separato, semplicemente per essere più flessibile per la configuration. (WD Raptor 300GB).

Quindi abbiamo configurato una coppia di 1 TB come pass-through, l'altra coppia è rispecchiata nell'host HV e detiene il VHD per entrambi i server.

Si noti che i dischi di passthrough distriggersno istantanee in Hyper-V-Console (vorrei che ci fosse un'opzione per escluderli, ma procedere con l'istantanea). Ho anche imparato il modo difficile che le istantanee erano comunque una ctriggers idea poiché rompe la sincronizzazione triggers della directory.

Il backup è su un disco esterno collegato all'host tramite e-sata.

  • Impostazione ad alte performance di PostgreSQL
  • Migliorare le performance di OpenVPN
  • Ciò dimostra una networking di strozzamento di width di banda di networking?
  • Apache2 mod_wsgi python 2.6 Django molto lento
  • Analisi di binlog di MySQL e strumento di reporting
  • Problemi di performance di MySQL dopo l'aggiornamento hardware e spostarsi in VM
  • Problemi di performance di NFS su Oracle Linux 6.7: Librerie condivise sul sistema di rallentamento NFS
  • Migliore prestazione: 1tb vs unità più grandi in app utilizzando solo letture / scritture sequenziali
  • 5 Solutions collect form web for “Requisiti Hyper-V, partizione del disco”

    Se non si prevede di utilizzare il sistema operativo host per eseguire qualsiasi cosa, tranne Hyper-V, non penso di mettere VM sulla stessa partizione come il sistema operativo sarà molto importnte. Sto utilizzando Hyper-V su un paio di workstation con dischi da 10k rpm con il sistema operativo su uno e VM su entrambi e non noto una differenza nelle performance VM tra di loro.

    Puoi mangiare velocemente il disco con i VM, quindi vale la pena avere un disco grande e lento per archivi e backup (forse non necessario se hai una buona archiviazione di networking e una networking veloce).

    Se lo stai costruendo e vuoi rimanere in un budget ragionevole, suggeriscoi dischi da 4-6x 10 rpm in raid 10 (300 GB di dischi possono essere utilizzati per ~ 200 dollari ciascuno su NewEgg). Poi forse 2x 1-2TB dischi in raid 1 (se si aggiunge questo, si potrebbe anche mettere il sistema operativo su di esso).

    L'utilizzo di dischi e snapshot dinamici in espansione influenzano negativamente le performance (per la virtualizzazione di una workstation va bene, perché forse un server). E per qualsiasi servizio intensivo su disco, utilizzare l'accesso diretto al negozio di backup del servizio (ad esempio, database o file-server). Se sposta il bottleneck I / O dalla partizione OS virtuale, probabilmente puoi snapshot il server virtuale del server senza preoccuparsi delle performance.

    Infine – si potrebbe desiderare più di 8GB (Hyper-V non può condividere RAM non allocata, e l'host ha bisogno anche di alcuni) – ma dipende da quanto intensamente verranno utilizzati.

    Spero che questo sia utile. E se fai qualche sperimentazione e benchmarking, penso che molte persone sarebbero interessate a vedere i risultati. Come avete probabilmente notato, c'è una scarsa quantità di dati di performance in questo settore.

    In una macchina virtuale, il disco è il colpo di bottiglia più grande. Quando costruisco un VMHost, utilizzo un disco da 1TB con una partizione OS da 60 GB e utilizzi il resto per eseguire il backup delle VM. Utilizzo quindi 4 o 6 velociraptors in un raid 5 o 10. Quello dà loro la velocità che avranno bisogno e una certa ridondanza.

    Utilizzando il raid 1 con 2 dischi lenti 2TB sarà solo una malattia in futuro. Ancora una volta, il disco è il più grande bottleneck.

    PS con il costo e le spese generali che Server 2008 port, ho sempre usato Server 2003 con Virtual Server 2005 e ha funzionato ottimamente.

    Mettere il sistema operativo su un disco fisico separato è sicuramente utile se si sta eseguendo Hyper-V, perché ciò effettivamente funziona in cima a Windows, quindi il sistema operativo in realtà ha qualche overhead (a differenza di, ad esempio, ESX / i, che ha un'impressione veramente piccola); un disco dedicato (o arrays) per OS e file di pagina può davvero aiutare.

    Per quanto riguarda i VM: quale tipo di carico di lavoro avranno? Memoria? PROCESSORE? Disco? Se lavorano molto con lo storage, mettendoli su un disco fisico separato fornirà un vero vantaggio; se fanno un disco I / O molto basso, puoi metterli tutti nello stesso posto e non ci sarà alcuna differenza.

    Se si dispone di due VM molto intensive per il disco, vorrei andare con tre arrays RAID1, uno (piccolo) per il sistema operativo e il file di pagina e uno (abbastanza grande) per each VM.

    • Ha ancora senso mettere l'OS fisico su un disco separato? Sì, questa è ancora una buona pratica.

    • Quanto spazio su disco / RAM devo separare dall'OS fisico? Per lo spazio su disco, dipende da cosa si intende inserire sulla partizione padre. Per RAM, vado con 2 GB per il genitore pluse 64 MB per VM che sarà ospitato.

    • File Server: C'è una notevole differenza di un disco passato vs VHD? Qualsiasi preferenza per uno o l'altro per quanto riguarda il backup, Volume Shadow Copy Service, altre cose?

    Vednetworking generalmente una differenza appena notevole tra un passaggio attraverso il disco vs un VHD. Tuttavia, la gestibilità dei passaggi può diventare molto difficile. Dipende quello che ti interessa. Se vuoi get tutte le performance che puoi, vai con il passaggio. Se vuoi rendere il più semplice ansible gestire, vai con i VHD.

    • Dovrei dividere le parti OS virtuali (FileServer-OS, FileServer-Data, CRM) su dischi fisici separati? Diciamo, con mirror 2x2x1TB o 2x2TB?

    Ho diviso VM OS e unità di dati e li metto su VHD diversi. Generalmente le migliori pratiche dalla mappa del mondo fisico al mondo virtuale. Mettere i VHD su differenti mandrini fisici dipendono totalmente dal carico di lavoro del file server e dal budget. Probabilmente non mi preoccuperei troppo.

    • Come si fa a sostenere una VHD di 'vita'? "come al solito" dall'interno del server?

    A less che non si disponga di una SAN nel backend, di solito si esegue il software di backup sui VM come nel caso di una macchina fisica.

    • Ha ancora senso mettere l'OS fisico su un disco separato?

    No. Utilizzo un Raid 10 sul mio server principale per i dati del sistema operativo e iper-v.

    • Quanto spazio su disco / RAM devo separare dall'OS fisico?

    Uso standard 64gb. Vuota, però.

    • File Server: C'è una notevole differenza di un disco passato vs VHD? Qualsiasi preferenza per uno o l'altro per quanto riguarda il backup, Volume Shadow Copy Service, altre cose?

    No. Non nota. Anche l'espansione non è notevole. Misurabile, sì. Faccio passare per le cose principali dei dati – soprattutto perché mi garantisce i budget IOPS. Perché il disco è singolo onwned.

    • Dovrei dividere le parti OS virtuali (FileServer-OS, FileServer-Data, CRM) su dischi fisici separati? Diciamo, con mirror 2x2x1TB o 2x2TB?

    A che punto, si parla di server REALLY low end qui. Ok, ho diviso server più grandi in file vhd diversi – perché il mio standard vhd è 64gb (sysprepped, utilizzando un differntial per avviare il sistema operativo reale da). Spazi grandi sono VHD separati.

    Proprio come informazioni: Server attualmente ha 64gb. 6x300gb Velociraptors per boot + vhs, 6x300gb Velociraptors Raid 10 per i dati SQL. Aggiungendo altri 4 dischi in gennaio. Il caso ha 24 slot – credo che abbia bisogno di un più grande presto. Posso fare il boot di circa 50 gb di VM senza problemi, ma quando inizia la giornata della patch, sento il carico IO. Così come wehn fare le importzioni di database. Ma poi, ho bisogno di un po 'di potere qui.

    I dischi 2TB sono SLOW. Ciò significa SLOW. Come REALLY slow. Best bang o il buck adesso sono WD Velociraptors, con un buon controller RAID (Adaptec)

    • Come si fa a sostenere una VHD di 'vita'? "come al solito" dall'interno del server?

    O esterno. Entrambi i modi funzionano. Nel server è più flessibile per il ripristino. Alcune cose che non sono backup su base server.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.