1. If you want to save some money on network cards you can use the same NICs in Virtual SAN server for Sync and iSCSI link. There is no need to spllt them into different VLAN. All you have to do is to assign secondary IP Addresses to the interfaces. For instance, NiC called 'Sync/iSCSI Interface' will have 192.168.100.11 for iSCSI traffic and 172.16.1.11 for Sync traffic.
2. Set the correct PSP. According to the Best Practices document it has to be Fixed for Virtual SAN server running on ESXi host. Make sure you select the correct preferred path to the local StarWind server to minimize the storage latency.
If the bigger part of workload is Sequential or Random Reads you may want to consider using Round Robin PSP to benefit from Read striping across both Virtual SAN servers.
3. Don't forget to Enable Jumbo Frames, but make sure you test performance before and after enabling this feature. There are rare cases when Jumbo Frames can lead to performance deterioration.
4. Make sure you properly test automatic storage rescan triggered by StarWind servers upon restart. That will ensure that ESXi server detects all datastores after reboot and manages to power on your VMs.
5. Configure and test Virtual SAN server to send all critical alerts so you don’t miss anything important, e.g. link failure or device going unsync.
6. If you chose to use Round Robing PSP I strongly recommend to change Default Round Robin limit from 1000 to 1 as per VMware KB2069356. I will explain why it is so important in Part 5.
I have also spotted that along with standard deployment options of StarWind which are described in great details by Vladan Segret (1, 2, 3) there is another interesting deployment option which actually built-in Virtual SAN management console.
3. Don't forget to Enable Jumbo Frames, but make sure you test performance before and after enabling this feature. There are rare cases when Jumbo Frames can lead to performance deterioration.
4. Make sure you properly test automatic storage rescan triggered by StarWind servers upon restart. That will ensure that ESXi server detects all datastores after reboot and manages to power on your VMs.
5. Configure and test Virtual SAN server to send all critical alerts so you don’t miss anything important, e.g. link failure or device going unsync.
6. If you chose to use Round Robing PSP I strongly recommend to change Default Round Robin limit from 1000 to 1 as per VMware KB2069356. I will explain why it is so important in Part 5.
I have also spotted that along with standard deployment options of StarWind which are described in great details by Vladan Segret (1, 2, 3) there is another interesting deployment option which actually built-in Virtual SAN management console.
What it does is it builds Virtual Storage Appliance image using combination of free Windows Hyper-V Core Server image and StarWind software.
The simple wizard guides you through several steps helping you to choose ESXi host and datastore where VSA will be deployed, the network to connect VSA management interface to, etc.
This choice can be useful, for instance, in Linux centic environments where system administrators don't deal much with Windows servers or when running free ESXi servers and not being able to deploy Windows VM from a template. It is not a killer feature for sure and it definitely could be improved to minimise the number of post-deployment configuration steps, but it is a useful addition to deployment options.
This choice can be useful, for instance, in Linux centic environments where system administrators don't deal much with Windows servers or when running free ESXi servers and not being able to deploy Windows VM from a template. It is not a killer feature for sure and it definitely could be improved to minimise the number of post-deployment configuration steps, but it is a useful addition to deployment options.
No comments:
Post a Comment