HellStorm666 schreef op donderdag 13 december 2018 @ 11:17:
[...]
Geheel terecht.
Het zou een stuk beter kunnen nog.
Al verweer waarom dit wel:
We zijn niet echt een groot bedrijf (22 man totaal)
Consumer sata drives staan in RAID1 dus 1 defect is nog geen probleem
RAID5 is maar met 4 disks
Single node is wel redundant uitgevoerd (dual PSU met elk een eigen UPS, dual LAN, dual CPU)
2x per dag een incremental backup naar een externe schijf.
1x per week een full backup naar externe schijf welke in roulatie is met totaal 3 externe schijven.
Maar tips over hoe ik het nog beter aan kan pakken hoor ik wel graag.
Zeker als we de overstap gaan maken naar ESXi.
EDIT:
Wat zijn de hardware P states?
16-core is vergeleken met de vorige server enorm weel meer (xeon met 4-core)
Hoe stel jij de front/backend verdeling voor? Nu wél het juiste moment voor ons om dat goed te doen.
Op hele kleine omgevingen kun je bijna niet anders dan front en backend combineren, maar dan moet je wel maatregelen nemen. De backend voorziet meerdere gebruikers een desktop machine een enkele gebruiker, die laatste mag dus nauwelijks invloed op de eerste hebben.
Hier is een stukje wat ik een tijd geleden geschreven het voor Horizon 7 with VMware Cloud on AWS, maar de principes zijn ook hier van toepassing:
Memory Reservation
As physical memory cannot be shared between VMs and swapping or ballooning should be avoided at all costs all memory should be reserved for all Horizon VMs. A memory reservation on VM-level protects only the consumed physical RAM. Windows zeroes each page available during boot, hitting the full reservation during boot time. Linux, however, only accesses the memory pages it requires.
CPU Reservation
A reservation specifies the guaranteed minimum allocation for a virtual machine.
vCenter allows you to power on a virtual machine only if there are enough unreserved resources to satisfy the reservation of the virtual machine. The server guarantees that amount even when the physical server is heavily loaded. The reservation is expressed in concrete units (megahertz or megabytes).
For example, assume you have 2GHz available and specify a reservation of 1GHz for VM1 and 1GHz for VM2. Now each virtual machine is guaranteed to get 1GHz if it needs it. However, if VM1 is using only 500MHz, VM2 can use 1.5GHz.
Reservation defaults to 0. You can specify a reservation if you need to guarantee that the minimum required amounts of CPU or memory are always available for the virtual machine.
As CPU reservations are shared when not used, for the management components it makes sense to reserve all CPU available. (example for CS:4*CPU frequency, UAG: 2*CPU frequency)
Any VM that serves all users should never be impacted by the load of single user.
For VMs that serve multiple users (like a Remote Desktop Session Host) a higher share could be given. (Example: a 2 vCPU VDI machine serves a single user, a 8 vCPU RDSH serves 28 users, but by default would only get 8/2=4 times the share, so it’s share should be increased by 28/4=7x)
Reservation on VM and Resource Pool
As VM level reservations are only taken into account when a VM is powered on, the reservation could be taken by other VMs when it’s powered off temporarily, setting reservations on both the VM and Resource Pool makes sure this doesn’t happen.
As Resource Pool reservations are for anything in the pool extra VMs added later could take resources required, also setting an expendable reservation at the VM level addresses this and ensures we keep the reservation at HA failover time, which powers the VM on at the (invisible) root resource pool level.
Leveraging CPU Shares for Different Workloads
Because RDS hosts can facilitate more users per vCPU than virtual desktops can, a higher share should be given to them. When desktop VMs and RDS host VMs are run on the same cluster, the share allocation should be adjusted to ensure relative prioritization.
As an example, if an RDS host with 8 vCPUs facilitates 28 users and a virtual desktop with 2 vCPUs facilitates a single user, the RDS host is facilitating 7 times the number of users per vCPU. In that scenario, the desktop VMs should have a default share of 1000, and the RDS host VMs should have a vCPU share of 7000 when not deployed to a separate cluster. This number should also be adjusted to the required amount of resources, which could be different for a VDI virtual desktop session versus a shared RDSH-published desktop session.
Hardware P states (Enhanced Intel SpeedStep) zijn nodig om de turbo te kunnen gebruiken, toevallig heb ik het zusje van jouw bord (X10DRH-iT, identiek, maar dan geen onboard LSI):
Advanced >> CPU Configuration >> Advanced Power Management
Power Technology >> Custom
Energy performance Tuning >> disable
Energy performance BIAS setting >> performance
Energy efficient turbo >> disable
Advanced >> CPU Configuration >> Advanced Power Management >> CPU P state control
EIST (P-States) >> Enable
Turbo mode >> enable
P-state coordination >> HW_ALL
Advanced >> CPU Configuration >> Advanced Power Management >> CPU C state control
Package C-state limit >> C0/C1 state
CPU C3 Report >>disable
CPU C6 report >> enable
Enhanced Halt state >> disable
Dan over hoe ik zoiets zou doen, ik zou 4 kleinere hosts pakken (Xeon E/Xeon E3, zoals E-2124 of E-2126G) met VSAN op NVMe aan twee 10Gbit switches en USB boot. Geen single point of failure en veel betere performance (IOPS, queuedepth en CPU frequency, lagere impact van Spectre/Meltdown door nieuwe architectuur), plus je kunt maintenance doen zonder downtime. Ook zou ik DC, DHCP, DNS, SQL en FS op VM level redundant maken, waarbij je DC, DHCP, DNS combineert.
Ik snap dat dit een beetje anders is dan de aanbeveling die ik meestal in dit topic doe (1 grote host), maar een thuislab is wel iets anders dan een omgeving waarop een bedrijf productie draait.
De voordelen van RAID5 zijn minimaal na aftrek van de nadelen:
- Schijven sterven vrij vaak vlak na elkaar, voor je de kans hebt gehad er één te vervangen.
- Door de amplification verlies je een stuk performance. En met SATA drives zit je al met je queuedepth in de knoei.
- RAID controllers zorgen voor meer fouten dan HBA's.
De combinatie van deze zaken is waarom vrijwel iedereen SAS met RAID10 (aanbevolen) of RAID6 gebruikt.
[
Voor 4% gewijzigd door
|sWORDs| op 13-12-2018 15:25
]