TOP

How SSD Storage Makes Your VPS Faster

Samsung 840 PRO SSD on OpenVZ Servers

There has been a lot of buzz in the industry lately about SSD storage, the benefits to I/O speed that it brings relative to it’s cost is something that makes it an attractive investment for both business and personal use.

This post should clarify the common questions you’re faced with when deciding if the added cost of using SSD based storage is really something they should invest in.

The image below is a very simple (and standard) benchmark test used to see what the sequential write speed of your filesystem is. Typically speaking anything above 80-120 MB/s on this test is an indication of a filesystem powered by something more powerful than the typical 4 SATA drive RAID10 setup. In this case, the test below was the result of a two drive RAID1 setup with Samsung 840 PRO SSD drives. The theoretical maximum write on these drives is about 450 MB/s.

IO Test on Samsung 840 PRO

So what does this do for you? Well, knowing the read and write performance of your underlying file system can help solve problems and plan for future growth of your website, applications and or database performance. I/O is often the most commonly over looked parameter when sizing up a server to run in a production envoronment. The typical CPU, Memory & Disk Space are the common 3 factors that are used to determine a comparison in price point amongst hosting companies. Unfortunately, not many will post the I/O performance of the disk space that is sold.

Common Questions to Ask

  1. Are you running a web application that requires the use of a Database?
  2. Do you require a lot of storage space?
  3. Does your application or task do more reading or writing to disk?

Generally speaking, if you don’t need hundreds of gigabytes of storage space and you are using some type of database, SSD based storage will make a noticeable difference immediately. Most times, if you are on older hardware with SSD real world performance can actually greater than state of the art hardware that is experiencing an I/O bottleneck.

At OpenVZ.ca, SSD storage can be added to any existing or new plan at an additional cost of $5 /month. It will require a migration to another physical node setup with SSD storage, but this migration is seamless and results in no downtime.

Read More
TOP

How to Ensure the IPv6 Default Route is Active On Boot

IPv6 World LaunchA common issue we notice is that users who have IPv6 enabled on their VPS have connectivity issues when rebooting. The problem 99% of the time, is the default route for IPv6 traffic is not present. By default, OpenVZ virtualization doesn’t seem to add the default route via the venet device unless specified by the user (unlike IPv4 behaviour).

The solution

Type the following command as root:

ip route add ::/0 dev venet0

While the above solution will work, it is not practical as most admins don’t want to manually type this each time they restart network services or reboot their machines.

To ensure the default route is present on boot. Add the following 2 lines of code to the /etc/sysconfig/network file.

NETWORKING_IPV6=”yes”
IPV6_DEFAULTDEV=”venet0″

This will ensure that your OS will add the default route for IPv6 on boot.

Read More
TOP

Reducing SPAM on your Postfix Mail Server with the Help of Public RBL/DNSBL Black Lists

A few months ago, we wrote about using “grey listing” on your mail server to help reduce SPAM. While, this concept works great in practice, it does have one major flaw that may affect your users if they are using their mail in time critical environments. Since grey listing initially rejects the mail and waits for a second attempt from the sending mail server to deliver the mail (SPAM servers usually only try one attempt) this eliminates the “instant” delivery of your emails. We all know that emails should never be depended on to be delivered instantly, but these days it’s very close to instant, majority of the time.

As a result, we want to share some other methods on how to reduce incoming SPAM to your mail server and users while preserving the quick delivery so many users count on each day. After all, we live in a world where expectations in technology are consistently rising.

Using a publicly available Black List Database, also known as RBL’s or DNSBL’s (DNS Block List, or Real Time Black Hole List) will allow your mail server to connect and verify whether the sending server is known as a SPAM sender. While there are many different types of Black List’s on the Internet, and we cannot guarantee (nor can they) that they are 100% effective in blocking SPAM, we would like to share a list of the common ones that we have used and are effective.

What to look for in a DNSBL Database

What you want to look for is a well maintained project (since this will be making decisions for you in real time) and one that is well known not to have what are called “False Positives.” In all cases, what you want to avoid when implementing an automated system like this, is the rejection of legitimate email.

DNSBL’s Suggested

The DNSBL’s that we have seen to be effective include the following:

  • zen.spamhaus.org
  • xbl.spamhaus.org
  • rbl.spamhaus.org
  • b.barracudacentral.org
  • bl.spamcop.net

DNSBL’s to Avoid

  • blackholes.five-ten-sg.com

Five-ten-sg.com is very prone to listing entire subnets (up to /24 in some cases) rather that listing individual /32 IP addresses. As a result, using this black list is very prone to attracting false positives and it is not up to date. There are many stale records that we have encountered in this database, sometimes including domains such as Apple’s @me.com and Googles @gmail.com. Avoid this database at all costs.

Implementation

Once you have researched which database (or combination of databases) you want to use, implementing it in postfix is as simple as adding one line for each database you want to include in your main.cf file.

Find the following line in your main.cf file:

smtpd_recipient_restrictions =

Add the following to what is already there:

reject_rbl_client pbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client xbl.spamhaus.org,

Again, you can use as many databases you like. In the case of spamhaus.org, it’s best to visit their website to see what the criteria is for getting on to the database (some are more strict than others).

Overall, using a DNSBL is effective in helping with reducing the amount of incoming SPAM on the network. It is a database that works in real time, and there are professionals out there who contribute information to these databases daily to help reduce the amount of SPAM on the public internet.

Read More
TOP

Using Email Greylisting to Reduce SPAM

One of the most common problems faced by anyone hosting a mail server in today’s internet world is SPAM. Whether it comes from the outside world to your clients or originating from your clients themselves. Every server administrator will need to deal with this at some point. This article is to clarify what “Greylisting” means, what it will do, what it won’t do and hopefully give you enough information to decide whether or not it’s a good idea for your environment.

In short, Greylisting does two main things. The first, is to temporarily reject the first email received from a non-whitelisted sender, the second is to keep a list of possible spam servers to chose whether or not to reject the first email.

This does sound a little weird at first, but the methodology behind rejecting the first email comes from a basic principle. SPAM servers generally send a lot of mail OUT. The faster the better (in most cases) as Administrators try to shut down these servers through blacklist databases all the time. Since these servers gernerally process a large amount of outgoing mail from potentially old mailing lists or manually created ones in some cases, most spammers don’t always know what email accounts actually exist. Going on this priciple, majority of SPAM server will not try to deliver mail more than once (ie: if it sent mail gets rejected it will not try and resend it). A properly configured mail server will try multiple times before sending it back undelivered.

As a result, Greylisting takes advantage of this by initially denying the message and waiting for the origin server to re-send it. If it receives a second request for the original message then it will accept and deliver it locally.

The most common configuration we use on our networks utilize Postfix mail servers with a plugin called PostGrey.  Although I won’t get into the configuration of PostGrey here, there are many articles online that can help you out.

Is Greylisting Right for You?

The reason you need to ask yourself this question is that it can provide benefits but at a small cost. Since Greylisting initially rejects the first email message, the immediate implications are that you will not get “instant” delivery of your mail. While most providers will never say that email delivery is instant by nature, it’s generally very fast. Normally within 1 minute of it being sent it should be received at the other end.

So if you are running a mail server that forwards messages to blackberrys or various handheld devices, these mobile users need to know that they will not get their messages “instantly” when they are sent by another user.

Also, mail servers can be configured in different ways. While most don’t wait very long to re-send a message, depending on the configuration the message could take up to 10 minutes to be re-sent. So it may not be a good idea to use this on a support or high-availability help-desk style situation.

The good news: You can exclude certain mail accounts from grey-listing. So you can still install and configure PostGrey on your server and specify which mailboxes to not Greylist.

Conclusion

GreyListing is very effective if you understand how it works and behaves. When used correctly it will reduce the amount of SPAM destined to your users by a very large factor (it did for us, but your mileage may vary).  In turn, this will reduce the amount of work other filters that are installed will need to do (IE: spamassassin etc…) thus allowing you to use much less resources for processing mail and limiting it to real mail in most cases.

 

Read More
TOP

What is the Difference Between “Guaranteed” and “Burstable” RAM on OpenVZ?

Another popular question we get at OpenVZ.ca is: “What is the difference between Guaranteed and Burstable RAM.”

To answer this question we must first briefly understand how OpenVZ works. Unlike other virtualization methods (XEN, VMWare) OpenVZ does not “Guarantee” system resources. Think of it more like a “chroot” of sorts. While it is not exactly the same as the chroot definition, it acts similarly to those principles. As a result the Virtualized Environments (VE’s) will share the Harware Node’s Kernel, RAM and SWAP space. From there, OpenVZ sets limits to each individual VE for such things as CPU speed and time, hard drive quota, hostname, IP addresses and more.

All of these limits are viewable in the following file on a OpenVZ based VE: /proc/user_beancounters

So how does all of this information relate to the amount of RAM on my VPS??

The important number is the Burstable amount. The reason for this is because the majority of programs allocate memory for more than what they actually use. Usually this is about double.

Lets take YUM for example. In order to run it, almost 100mb of RAM will get allocated, but it will only use about half that (there are variables here depending on what it’s actually doing). Majority of programs do this just incase they need more.

Example: If the “Small” package on OpenVZ.ca were to have 128mb burst and guaranteed RAM, running #yum update -y would lead to an error. This is because the yum program will try to allocate about 100mb of RAM. OpenVZ will see that this is higher than the burstable limit (assuming there are other things running as well), resulting in the error.

Since the “Small” VPS package has a burstable amount of 256mb it allows YUM to excecute perfectly. The actual RAM usage is under the guaranteed 128mb and the allocated is under 256mb.

Summary

The Guaranteed RAM is the amount the can be used, the Burstable RAM is the amount that can be allocated. Generally assume that the program will allocate double the RAM it uses.

Recommendations When Buying

In general, build up a good relationship with your host and make sure they are honest with you. There is nothing wrong with asking for the full spec of the hardware node and asking how many customers are on it or how much of it’s resources are allocated (or intend to be allocated).

From there it’s important to know just how much ram your system will be using. Always get double the amount of burstable ram to ensure that your programs will run perfectly. If you know your system will be using 512mb of ram, make sure that you get a burstable amount of 1gb or more. Always look at the burstable limit as a rule of thumb.

In the end, it’s your money and you need to make sure that it’s being well invested.

Read More