Category Archives: Web Hosting

Web Hosting

SolusVM no bandwidth stats on VPS/VM on Xen 4 slave

So I installed SolusVM Slave on a Xen 4 box and everything was working fine (create, reboot, delete, modify VPS/VM) except no bandwidth stats for the individual VMs.

I opened a ticket with SolusVM and it was not apparent what the problem was (to them) so they had me check various things:

1) Please can you run upcp on your Master in SSH

I did that, same results, no bandwidth counting on slave VPS/VM. So they suggest:

In a VPS on a Xen slave please download a large file such as a CentOS DVD and let me know if this counts.

Same thing, so I get frustrated and completely wipe out the Master, reinstall using the

backup database/restore procedure here:

And everything the same. And now from Solus:

Can you paste me this file please on your master: /usr/local/solusvm/log/bandwidth.log

So it showed no bandwidth counting on the Xen VPS.

I need to see your xen scripts, iptables config and a full output of iptables on the server.

Which showed no bandwidth counting.

I need the output of iptables -L -nxv

Which showed:

3352959 4971885604 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm101.0 –physdev-is-bridged
0        0 ACCEPT     udp  —  *      *             PHYSDEV match –physdev-in vifvm101.0 –physdev-is-bridged udp spt:68 dpt:67
0        0 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm101.0 –physdev-is-bridged
1514200 82967656 ACCEPT     all  —  *      *           PHYSDEV match –physdev-in vifvm101.0 –physdev-is-bridged
36405 54415322 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm101.0 –physdev-is-bridged
0        0 ACCEPT     udp  —  *      *             PHYSDEV match –physdev-in vifvm101.0 –physdev-is-bridged udp spt:68 dpt:67
0        0 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm101.0 –physdev-is-bridged
15135   814960 ACCEPT     all  —  *      *           PHYSDEV match –physdev-in vifvm101.0 –physdev-is-bridged
26217  3811598 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm103.0 –physdev-is-bridged
0        0 ACCEPT     udp  —  *      *             PHYSDEV match –physdev-in vifvm103.0 –physdev-is-bridged udp spt:68 dpt:67
0        0 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm103.0 –physdev-is-bridged
3731   546174 ACCEPT     all  —  *      *           PHYSDEV match –physdev-in vifvm103.0 –physdev-is-bridged
10170503 15208761930 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm102.0 –physdev-is-bridged
0        0 ACCEPT     udp  —  *      *             PHYSDEV match –physdev-in vifvm102.0 –physdev-is-bridged udp spt:68 dpt:67
0        0 ACCEPT     all  —  *      *             PHYSDEV match –physdev-out vifvm102.0 –physdev

So Solus said:

You need to remove the mangle rules. They are stopping data passing over the bridge.

Which sounds reasonable so I:

iptables -F -t mangle

And it stays the same so I say: “What mangle rules?”

And they, in effect, tell me to clear iptables (iptables -F) and then let the Solus process redo them (in 15 minutes) which I did and now iptables is letting bandwidth to go through.

So I searched for the root cause of where those iptables lines were coming from as a

restart brought them back, found them in xen scripts:

# cd /etc/xen/scripts/
# grep physdev *
network-bridge:    iptables -A FORWARD -m physdev –physdev-in ${pdev} -j ACCEPT  iptables “$c” FORWARD -m physdev –physdev-is-bridged –physdev-in “$dev” \  iptables “$c” FORWARD -m physdev –physdev-is-bridged –physdev-out “$dev” \

# rpm -qa | grep xen

I commented out those lines and now on a restart the SolusVM Master is able to read bandwidth stats from the individual VPS/VM.

SimplicityHosting.Com, Inc. expands network to 9 geographically diverse locations

Please be advised SimplicityHosting.Com, Inc. operates in nine geographically diverse network centers:

Chicago, IL
Los Angeles, CA
Fremont, CA
Dallas, TX
Atlanta, GA
Newark, NJ
London, UK
Tokyo, JP
Scranton, PA

Individual machines & VPS’es may be requested for Mirror/Failover between any 2 locations and Global Distribution between 3 or more locations as well. Please drop us a line if you require these services or have questions.

Thank you – SimplicityHosting.Com, Inc.

SimplicityHosting.Com, Inc. – Mirrored System Redundancy and Failover System Now Offered!

Warning, the following post is a bit technical and will only interest those that have what we consider to be mission critical websites so if you do not require it you may skip to the bottom:

This notice is to bring you all up to date on the issue of Data Center redundancy. If you look out on current offerings many are offering 99.(insertnumbershere)% uptime guarantee. Where most of them are just winging it (just offer it and if a problem occurs and clients are lost that is part of doing business) some actually can track those uptimes and have Service Level Agreements in place as “guarantee’s”. Some of us realize how absurd these offers and the guarantees are, in the light of doing real business on the Internet!

For example, as you can never know when the data center (that has been up steadily for 3+ years) will have an issue (power outage,

upstream provider causes 45% of data connections to fail, hard drive on server(s) break, etc…) that issue could occur at a critical time for business transactions, or not! Let’s say does $10,000/day generally in business transactions online (we have clients that do more and some that do significantly less). And let’s say there is an outage of 5 hours which constitutes less then .01% downtime within any given year. Well the potential loss for this particular client could be exactly $10,000 (if most transactions occured within that time frame) or a fraction of that (evenly divided would be $2,083.33 for the 5 hours). So what would that client be ready to pay to mitigate the chance of that happening?!

The above is only one example of the need for a Redundancy Failover System which spans more then one Data Center (and in our case more then one State of the Union!), on entirely different data paths, and relying on many points (rather then single points) to guide that traffic to insure the transition is rapid in the face of an event.

The system we have designed essentially does this. We ran scientific studies that most sites complete and are visible to users after the switch in around 10 minutes or less. The studies we performed which include a wide spectrum showed that 92% off all Internet traffic will see the site at the new location within 1 hour and that 8% will trickle in after that. This is due to certain ISPs having sluggish or ignorant systems with respect to routing and caching of resources.

So SimplicityHosting.Com now has offerings for every service level for Redundancy and Failover. It works like this:

Mirror existing site and data to redundant server in separate physical Data Center (currently in different States).

Enable Monitoring / Failover System to fail over to the other data center when the first Data Center is unreachable.

The system is already tested and in place for some clients that have requested it. If you are in the category that cannot afford to have any downtime such as above mentioned please check out our offerings which are addons to your current package.

If you are a dedicated server client these addons do not show but will need to be quoted on a case by case basis (based on usage, amount of sites and some other factors) so please do not hesitate to open a support ticket to have this option quoted to you, or drop us a line if you are not a current client at SimplicityHosting.Com, Inc. There are some packages where the addon will not show up, if you are interested in the addon and it does not show please email [email protected] and make your request known.

Thank you for your continued business!

SimplicityHosting.Com, Inc.