Cheap Dedicated Servers

December 9, 2015 – 3:24 pm

In our industry lot of providers are offering cheap dedicated servers and many of them compete solely on pricing. As much you would like to blame the providers, it is the market culture which has went in one direction that is low prices.

With the low prices the quality of service has also gone down in many ways, for example;

  • Power Outages – Recently some of the cheap dedicated servers providers have experienced extended power outage repeatedly in the span of few months, WHY is that?
    1. To profit they have to compromise and base out of low cost facility.
    2. To save on costs not enough generators and ups are installed
    3. If the generator capacity is installed they do not get regular maintenance since that is additional cost.
    4. Fail to meet N+1 or N+2 redundant standard.

We at 24Shells have taken special precaution when it came to selection of the facility where our equipment is installed. We made no compromise on the cost of infrastructure and selected the premium facility.

Our datacenter facility offers N+2 redundant power and guarantees 100% uptime. This was proven in 2012 when Hurricane Sandy hit the shores of NY/NJ area and number of datacenters in the heart of New York experienced power outage. Our datacenter was one of the exception which did not experience any power outage and ran on generators for 12 days till the utility power was restored.

The transition from Utility power to Generator Power to Utility Power was seamless and none of our client experienced disruption of services.

The motto behind this article is to educate clients who are shopping for price only, we are not saying overpay for your server but be reasonable in your analysis of provider. Take caution when you find something is unrealistically cheap, it might make you happy for few months but in long run your business will suffer.

Always take a long term view in perspective when selecting cheap dedicated servers.

High Availability WordPress Dedicated Server Hosting

October 31, 2015 – 12:51 pm

In this example we are going to look at building a high availability and resilient setup for hosting a busy website, such as WordPress. Our environment will consist of 5 servers. 2 will be used for load balancing with failover, with the other 3 being used to build a MariaDB Galera cluster and a distributed replica filesystem using Glusterfs. You can use as many servers as you require.

CentOS 7 – This guide is for CentOS 7 only and will not degrade well with older versions.

#Begin
We will start with the cluster.
The first thing we need is to update the systems and ensure you are running the latest patches.
NOTE: Until further notice the following needs to be repeated on every node you intend to run in your cluster – but not your load balancers we will cover the load balancers later.

#Update the systems
yum -y update

#Install the repositories
Once the system is up to date you need to install the required repositories.
The first repository we will need is the EPEL repo. This can be obtained from the following link at the time of writing this:
rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

The next repository we need is the MariaDB repo. We can add this ourselves with the below command:

echo “[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.0/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1” > /etc/yum.repos.d/MariaDB.repo

#Install the required software
Now we are ready to install the software.
The following command should get the job done in one shot:

yum -y install socat MariaDB-Galera-server MariaDB-client rsync galera glusterfs-server glusterfs glusterfs-libs glusterfs-fuse php httpd mod_ssl php-gd php-mbstring php-xml php-common php-mysqlnd php-pecl net-tools

#Prepare the environment
Now that all software is installed we can begin our basic configuration tasks, starting with the environment. NOTE: We are still repeating these steps on each node.

#Security
Firstly we need to set SELINUX to permissive mode. Execute the following command:
setenforce 0
You should also edit the config file in /etc/selinux/config to ensure that permissive mode is retained through reboots. Failure to do so will result in a non-functional setup after a reboot.

#Firewall
To ensure everything can communicate we need to add a few rules. NOTE: Assuming that the firewalld configuration is default on your freshly installed system. Use the following commands to open the required ports.

firewall-cmd –permanent –zone=public –add-port=22/tcp #Change this to match your SSH port
firewall-cmd –permanent –zone=public –add-port=80/tcp
firewall-cmd –permanent –zone=public –add-port=443/tcp
firewall-cmd –permanent –zone=public –add-port=3306/tcp
firewall-cmd –permanent –zone=public –add-port=4567/tcp
firewall-cmd –permanent –zone=public –add-port=4568/tcp
firewall-cmd –permanent –zone=public –add-port=4444/tcp
firewall-cmd –permanent –zone=public –add-port=111/tcp
firewall-cmd –permanent –zone=public –add-port=111/udp
firewall-cmd –permanent –zone=public –add-port=2049/tcp
firewall-cmd –permanent –zone=public –add-port=24007/tcp
firewall-cmd –permanent –zone=public –add-port=38465-38469/tcp
firewall-cmd –permanent –zone=public –add-port=49152/tcp #Glusterfs Brick NOTE: that each brick can use its own port so be sure to adjust this when required. If you have a problem with communication then disable the firewall and use the command detailed below to determine the correct brick ports before enabling the firewall again.

In order to make these rules apply to runtime we will need to restart the firewall service:

systemctl restart firewalld

#Network
Now we need to ensure that each of our systems can quickly find each other without the need for any external resolver queries. To do this we need to edit the /etc/hosts file. Below is an example of what you can do.
echo “10.10.0.1 server1 server1.example.com
10.10.0.2 server2 server2.example.com
10.10.0.3 server3 server3.example.com” >> /etc/hosts

#Database
To start we first need to initialise and secure MariaDB. Run the following command and answer yes to all the questions:

/usr/bin/mysql_secure_installation

Once the above is complete you will need to configure the user privileges for the MariaDB cluster. You can do this from the MySQL console by typing the following commands. NOTE: You need to do this on each system.

mysql -u root –password=thesecurepassyoujustmade mysql
DELETE FROM mysql.user WHERE user=”;
GRANT ALL ON *.* TO ‘root’@’%’ IDENTIFIED BY ‘asecurepass’;
GRANT USAGE ON *.* to sst_user@’%’ IDENTIFIED BY ‘asecurepass’;
GRANT ALL PRIVILEGES ON *.* to sst_user@’%’;
FLUSH PRIVILEGES;
quit

NOTE: You are free to restrict the hosts (%) from where the users can connect; root was already disabled from remote logins by the secure installation step above.

The next step is to configure the actual MariaDB server variables where we can define the settings required for our cluster to work properly. Stop MariaDB-server on each node with the following command:

systemctl stop mysql

#Server1 (10.10.0.1) – Acting as the master MariaDB server in this phase of the setup.
Type the following command to input the below config. You are free to edit the config as you see fit; however, this will get you up and running. NOTE: Adjust IP’s, names and password to the correct settings for your environment.

echo “binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=”gcomm://10.10.0.1,10.10.0.2,10.10.0.3″
wsrep_cluster_name=’galera_cluster’
wsrep_node_address=’10.10.0.1′
wsrep_node_name=’server1′
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:asecurepass” >> /etc/my.cnf.d/server.cnf

Now that the config is set you need to start the server. In order to start everything required you need to append a flag to the start up process as shown below:

systemctl start mysql –wsrep-new-cluster

#Server2
The only difference in the next two servers is the IP addresses, names and the initial start up of MariaDB.

echo “binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=”gcomm://10.10.0.1,10.10.0.2,10.10.0.3″
wsrep_cluster_name=’galera_cluster’
wsrep_node_address=’10.10.0.2′
wsrep_node_name=’server1′
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:asecurepass” >> /etc/my.cnf.d/server.cnf

Now start MariaDB in the normal way:

systemctl start mysql

NOTE: The start up process will take longer than usual whilst MariaDB joins the cluster.

#Server3

echo “binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_locks_unsafe_for_binlog=1
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
datadir=/var/lib/mysql
innodb_log_file_size=100M
innodb_file_per_table
innodb_flush_log_at_trx_commit=2
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=”gcomm://10.10.0.1,10.10.0.2,10.10.0.3″
wsrep_cluster_name=’galera_cluster’
wsrep_node_address=’10.10.0.3′
wsrep_node_name=’server3′
wsrep_sst_method=rsync
wsrep_sst_auth=sst_user:asecurepass” >> /etc/my.cnf.d/server.cnf

systemctl start mysql

Now that we have completed the setup of MariaDB Galera cluster we should do a little testing to ensure that it is working as expected. Run the following command from server1 console:

mysql -u root –password=yoursecurepass -e “show status like ‘wsrep%'”

The output we are interested in is in the following lines:

wsrep_local_state_comment | Synced
wsrep_incoming_addresses | 10.10.0.1:3306
wsrep_cluster_size | 3
wsrep_ready | ON

As you can see above the cluster size states 3 which means each of the nodes we prepared have joined and are operational. If you re not seeing the output as above then it is likely that there is a communication issue between the servers. Check the firewall.

#Filesystem -GlusterFS
Creating our distributed filesystem is a relatively painless task. With the required software already installed we simply need to execute a few commands
Firstly start the GlusterFS daemon on each box:

systemctl start glusterd

On server1 type the following commands:

gluster peer probe server2
gluster peer probe server3

This should have found the second and third peers. To confirm type:

gluster peer status

It will show you the number of peers. If it does not, check your firewall configuration to ensure the required ports are open. You can disable the firewall temporarily if required to allow you to probe the peers and determine the ports they are using.

Now that we have our peers we can proceed to creating a GlusterFS volume. The following command can be edited to suit your own naming conventions. NOTE: These next set of commands relating to volume creation should only be run on server1.

gluster volume create wordpress replica 3 transport tcp server1:/wordpress server2:/wordpress server3:/wordpress force

NOTE: I have used the force flag which enables the creation of the volume inside the root / partition. Omit the force flag if you intend to create your own partition specially for this volume. It is up to you.

Now that we have created the volume we need to start it.

gluster volume start wordpress

We should now consider security and add an acl.

gluster volume set wordpress auth.allow 10.10.0.1,10.10.0.2,10.10.0.3

In order to use the newly created volume we first need to mount it to a directory. The following command should be typed on each of the servers 1 2 and 3.

mount -t glusterfs localhost:/wordpress /home/your_user_folder/webroot

NOTE: change the path according to your preference.

Now that we have an active distributed filesystem, any of the files we put into the mount directory will replicate to the other nodes.
In order to ensure these mounts come back automatically upon reboot you should add them to the /etc/fstab file on each node. It will look something like this:
localhost:/wordpress /home/your_user_folder/webroot glusterfs _netdev,fetch-attempts=10 0 0

#Setup your website
Now is the time to setup your website. Configure Apache (on each node) in the normal way to ensure it is pointing to the webroot directory in the step above. On server1 login to MariaDB and create/upload your WordPress database in the usual way. Be sure that your WordPress database is configured to use the innoDB engine. If it is not phpmyadmin has a decent little conversion utility – use it and save yourself some time and pain. NOTE: When placing your website files and folders on server1 you may need to ensure that permissions are setup properly on your folders. I also strongly recommend you disable any WordPress cache and database cache plugins at this stage. To ensure that files and folders have the correct permissions go to server1 and cd to the mount directory and type the following commands:

chmod 755 $(find . -type d)
chmod 644 $(find . -type f)
chmod 777 wp-content/uploads

NOTE: These commands can take a considerable amount of time to complete depending on the number and size of the files in the webroot. Be patient.

This completes the guide for the cluster.

Next we will need to build the load balancers.
In this scenario we are going to use HAProxy as the load balancing software.

#Load balancer servers

To start with get the servers up to date

yum -y update

Now you need to again install the EPEL repository.

rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

#HAProxy

To install it type the following:

yum -y install haproxy

Next we need to configure it.

What it takes to setup a successful Reseller Hosting Business

October 23, 2013 – 7:41 am

With the market this vehemently loaded, how is a new reseller expected to make space? What all marketing strategies can help a reseller find slot in the web hosting arena? If questions of this sort happen to bang your grey cells at all hours, this post might offer relief.

Well, to begin with it is important to accept the fact that perhaps whatever your website hosting offer is, there will be others in the market, providing exactly identical terms or maybe better. Thus, there is nothing exceptionally unique that you can come up with. But don’t let this discourage you, because there are other areas you can work at, and the top in the list here is ‘relationships’. Now there are two scenarios here. One, you are already running or are engaged in an IT business and have thought of web hosting reseller setup as a business extension or possibly an add-on. Second, you have absolutely no entrepreneurial existence in the IT zone and the whole idea of making online income has prompted this decision.

In the first case, playing the relationship card can be easier; you already have the startup platform. There are existent clients, who are in need of websites or already have them and in either case need web space. Selling web hosting contracts to these people is like cashing on the rapport you already have. Start spreading the word around that you have also ventured into web hosting business. Don’t forget to mention that alongside the services you are already extending, are willing to go a step forward and assist with this web requirement. Start casual and step up the next level by seeking dedicated appointments for this new business proposal. If the other party doesn’t seem interested, send periodic mails and make sure you are always remembered. Basically in this case, your existing reputation and contacts plays a pertinent role. If you have created a trustworthy image, getting into the web hosting business will be easy.

Coming over to the situation where you are absolutely new, reseller web hosting business has to begin with a catchy introduction. Make a website, which is interestingly designed and offers captivating content. You will also need flyers and mailers to support the marketing slant. Online advertising is an expense you will have to bear. Contact web designers, perhaps attend seminars and exhibitions and establish a dialogue with code developers and graphic artists and content writers and others who you feel have an access to the web market. Establish relationships that can help you form a referral chain. Perhaps, reaching on directly to the client might be a little difficult, but you would be surprised how in the website hosting industry, referrals play a pivotal role. So form friendships …they will lead you to the real slot.

Break the trap … changing a web host is no big deal after all!

September 30, 2013 – 4:39 am

Terribly slow website, recurrent security threats, frequent virus attacks, sloppy mail accounts and all such related problems are caused by one bad decision – selecting a web hosting company, which is not really the best. However, while many realize that they have made a mistake, most still continue with the redundant choice, they once made. Not essentially because getting a cheaper and a better web hosting offer seems difficult, but more so because the whole idea of moving a website to another web host seems too painful a job to accomplish. But can we actually afford to lose out because we are scared of the transition? And in fact is the transition really that big a hassle to be avoided?

Well, moving a website to a new web host can appear to be a daunting process, but it really isn’t. The key part of the process is finding an appropriate new web host and if that part is dutifully settled, the rest will be taken care of.

How…
Basically, with the new web hosting service provider, if the company is good enough, you will not have to spend a stupendous price for this switching decision. In fact, most offer the facility of free website transfer. Thus, you pay for the services you avail and nothing extra is spent upon the website moving process. After all, it is anyways mentally taxing, then why must you spend anything more?

Next, the new web host will manage the entire copying process. The idea is to have two web hosts for a short span of time, so that the files from the previous host can be safely restored. You will need not just the files, but also the databases. The technicalities involved in this transfer / copying process will again be managed by the new web host. Here it is advised that if you are contemplating a shift to another web hosting company, it is better to first make fresh copies of all data and then inform the old web host. Else, there might be downtime hassles, which certainly are not desired. Besides, it is better to maintain a safe side and thus ensure diligent transfer.

Domain name is next on list. If purchased from a third party, changes of any sort won’t be an issue; however, if your previous web host is the seller of your existing domain name, you will have to get in touch with them for the changes. It is a minor replacement and the web host shouldn’t really take much time to process the domain change request. It takes a while, a few hours for the new site to get loaded and once the site with new web host is up, you can terminate the old contract. So basically, a little time invested in the web host search and you are all sorted!

Attributes that define a good Web Host

September 30, 2013 – 4:37 am

The whole idea of a well managed website and the smooth web transition process relies primarily upon the service capabilities of the selected web hosting company. If the web host, who is selling you the online space, is able to smoothly handle your web traffic and is flexible enough to swiftly accommodate changing needs, you are all sorted. However, in order to get a minor bug fixed, if you have to call the web hosting service provider, more than once, your website is in sloppy hands. Poor customer service, recurrent security issues, increasing instances of downtime, slow speed and pricey adjustments together define a bad web hosting experience. If your website shows any of the listed symptoms, the medical condition is definitely poor and you must immediately switch to another care taker.
As you begin this search process, first and foremost keep the price factor aside. Neither too expensive is the best and nor is a free account good enough. How much you pay, can only be justified, in terms of what you are getting from the web host in return. Thus, only checking out the prices and ignoring the offer is definitely not a good start.

Now coming back to the requirements, a web host who can meet the following criterion ought to be selected:

• Uptime, bandwidth and speed – A website that is often down is as bad as dead. Especially, if it is a commercial website, you don’t want frequent delays as that would simply push your prospective customers towards competitors. Select a web host who can commit at least 99% uptime and this really isn’t a big deal. In fact, once you will scan through the web hosting service contracts, statements like 99.5% or even 99.9% will appear; so settle for no less. Likewise, when it comes to bandwidth, which defines the amount of data that can be transferred, unlimited bandwidth is a term that has been coined to fool naïve customers. Many web hosts claim that their offer includes unlimited bandwidth, but for websites serving high traffic, the truth soon falls apart. Suddenly, the unlimited clause vanishes and in the next bill, you are charged for excessive usage. The point here is that when you sign a contract, scan it thoroughly and make sure that each and every clause is clearly noted.
• Security – SSL security layer is a mandate requirement for an e-commerce website and in addition, for all websites, the web host should be able to provide basic firewall protection and must have the needed tools to keep your website absolutely clean.
• Customer Support – This is a really crucial aspect. Often customers take it for granted that the web host will be available at all times, however situation often changes once you have paid for the yearly contract. You must only go ahead with a web host who really is available 24 hours a day, 7 days a week. We are talking about a website here and any problem is an emergency. Thus, the doctor should be ready with solutions, at all times.
• Hosting Options – Pick a website hosting company that offers the entire hosting bouquet. Maybe be today you are going ahead with a shared web hosting contract, tomorrow the needs could change and managed web hosting or a dedicated plan might be needed. The web host thus should be geared to assist with various plan choices.

Web Hosting … the industry better known for ‘COMPROMISES’!

September 25, 2013 – 12:07 am

Various surveys, conducted by agencies of repute, over time have established a critical fact regarding the web hosting services. A huge number of firms availing web hosting services are dissatisfied with what they are getting, but still are just continuing with the middling web hosting offer. Now the question is why … why aren’t people disgruntled? Why is it so that a change is not on the cards? How can ‘so-so’ be good enough?

1. Plain carelessness – All of them are the same, any is fine. This attitude explains a basic reason behind careless selection. At the outset, adverts from a number of web hosts might appear similar; however this doesn’t means that all web hosting service providers fall in the same category. Despite the fact, many firms however invest little or no time weighing the prospective service providers’ capabilities and usually just settle with whatever comes first.

2. Agents and advisors – Another large proportion of population is happy relying upon their chain of advisors. Be it the guy designing the website or an outside system maintenance agency employee, the first name that is referred is accepted.

3. Price Down – Cheapest is the best, why pay more when economical options can suffice. The illusion of availing more in lesser cost provokes incorrect selections. The notion that the cheapest web host is as good as others in the industry ensures such decisions. Clients end up paying less in monetary terms; however the overall costs for the compromises they make, are pretty significant.

4. Price Up – Higher the charge, better the offer. Another group is paying atrociously high price for web hosting services and yet is totally unaware of what they are getting. Primarily so because they feel that at this price, if this is the offer, anything better cannot really be possible. It is a situation where, because these firms are paying more, they are psychologically attempting to stay content.

5. The fear of change – My website is too slow, but change could kill. The web owner is pretty clear of the situation in this case; however, the transition from one web host to another is just too scary a proposition. Call it security threat or the fear of losing clients on account of transition delays or the involved costs, many companies are simply continuing with the existing web hosts because they believe that changing a web host is a costly affair.

Are you a participant of this compromised web hosting realm???

If you are not aware of the benefits a good web host can offer, at a nominal price or the pains currently caused by your web hosting service provider, you are intentionally contributing to this ill effect. In the net era, while we are so badly dependent upon internet, does it makes any sense to stay ignorant. Transitioning to another web host is absolutely a hassle free process, why then stick with the mediocre? If you are still not sure what ‘hassle free’ means here, the next post elaborates the benefits of a good web host and the following explains the website switching process and thus help you break the sick web hosting trap you are currently fenced in.