On Oct 26, 2011 8:55 AM, "kashani" <kashani-l...@badapple.net> wrote: > > On 10/25/2011 6:27 PM, Pandu Poluan wrote: >> >> (Sorry for the late reply; somehow this thread got lost in the mess) >> >> On Oct 12, 2011 2:03 AM, "James" <wirel...@tampabay.rr.com >> <mailto:wirel...@tampabay.rr.com>> wrote: >> >> > >> > Pandu Poluan <pandu <at> poluan.info <http://poluan.info>> writes: >> > >> > >> > > The head honcho of my company just asked me to "plan for migration of >> > > X into the cloud" (where "X" is the online trading server that our >> > > investors used). >> > >> > This is a single server or many at different locations. >> > If a WAN monitoring is what you are after, along with individual >> > server resources, you have many choices. >> > >> >> It's a single server that's part of a three-server system. The server >> needs to communicate with its 2 cohorts continuously, so I have to >> provision enough backhaul bandwidth from the cloud to my data center. >> >> In addition to provisioning enough RAM and CPU, of course. >> >> > > Now, I need to monitor how much RAM is used throughout the day by X, >> > > also how much bandwidth gets eaten by X throughout the day. >> > >> > Most of the packages monitor ram as well as other resource utilization >> > of the servers, firewall, routers and other SNMP devices in your network. >> > some experimentation may be warranted to find what your team likes best. >> > >> >> Currently I've settled on a simple solution: run dstat[1] with nohup 30 >> minutes before 1st trading session, stop it 30 minutes after 2nd trading >> session, and send the CSV record via email. Less intrusion into the >> system (which the Systems guys rightly have reservations of). >> > > You're not going to be happy with this design for a couple of reasons. > > 1. It's more expensive that your current setup. If the two servers at your datacenter are down I assume the server is the cloud is useless and vice versa. You already have to maintain infrastructure for those two servers so you're realizing no savings by eliminating on server from your infrastructure. Buying a $1500 rack server amortized over three years is a better deal than paying for equivalent power in the cloud. > > 2. Latency. You're increasing it. > > 3. Cloud performance varies. Networks split, machines run slow, it happens. You'll have more consistent performance on your own machines. It's getting better, but it's still something with which to be aware. > > Migrating to virtual servers makes some sense, but you need to look at it on a case by case basis. > > kashani >
Indeed. The fact is that the server-to-be-clouded is a trading server used by approx. 3000+ clients (investors). Our 20 Mbps line is barely able to cater them all, and my company has to pay through the nose for each additional Mbps. How big a nose? I'm looking at the quotation on my desk that says my.company needs to shell out 200 USD (excl tax) per additional Mbps per month... The traffic between that server and the other 2 is less than 20 Mbps, but how much less, that's what I'm trying to find out. As to latency... the "powers that be" had decided that, "... sucks to be trading on your own; better to go through our dealers... " :-P Rgds,
