| NowSMS and VMware ESX4 Cluster |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through December 23, 2009 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian New member Username: Animatele Post Number: 50 Registered: 06-2004 |
Bryce, Des: After much planning and testing, our servers running NowSMS have been virtualised one-by-one, and then migrated to a new powerful cluster. The process is smooth and straightforward. There are some peculiarities however: - a FAST and a COMPATIBLE storage is a must. A RAID array with compatibility issues with ESX had caused us much grief on the 1st try. - A lot of space needs to be allocated to volumes containing many small files, such as \Q, \SMS-IN, and username\q folders. VMFS minimum block size is 1Mb. The folder (by our bespoke app) containing indexed directories with 400K tiny files in them took up 60 GIGABYTES on the VMware datastore. Not a joke - physical storage for small files needs to be planned for at least 150% of the maximum number of files by block size. - best is of course to use super-fast SSD-s for queues. 8 Intel X25-E-s in RAID6 will beat a half-rack of spinning 15K SAS drives. - IMPORTANT to put the NowSMS folder on a fast volume too. The SQL Lite files in it used to track message IDs create about as much I/O load on storage as the main queue folder and message logging combined. - To take advantage of the VMotion feature, the storage needs to be shared among physical hosts. SAN connected via FC fabric is the conventional yet expensive solution, and it's the best. Those with less resources can use iSCSI SAN, but that often limits performance. - VMotion works without a hitch. A very busy server won't drop a single user bind or an uplink while jumping from one physical host to another. In the logs, the moment looks as if all activity stopped for a half-second. Amazing. - VMware clones the server's CPUID. No need to request a new license for virtualising the server, or moving it from one host to another. While migrating, running applications don't even need to be stopped. - There is no noticeable overhead despite the large file block size - provided that the cluster has ample storage and it's fast. Disk performance can be fine-tuned too, google "partition alignment in vmware". We've not yet tried NowSMS clusterisation features. Looks like there would be a lot of flexibility if it's done under ESX. Will report when implemented and tested. If anyone had particular experiences running NowSMS under VMware please share too. Kind regards, Ashot | |||
