Tuesday 4 November 2014

Physical Servers Vs Virtual Servers Vs Cloud

Physical Servers Vs Virtual Servers Vs Cloud

There can be several different reasons why Kenyan businesses ad companies are choosing either a Physical or Virtual Server for their day to day errands. Considerations such as business size, needs and price are all factors to take in to account. My goal is to give you a helicopter view of the key points of each so when you discuss the options best suited for your firm,you are informed on some of the terminology and factors.
Physical Servers:
Physical Servers are the traditional way of doing things (in IT traditional means more than 3 years ago!) and involve a piece(s) of hardware that are configured to perform the tasks of your business. Generally this hardware is in your server room or broom closet. They can play any role required in the business, from Mail Server to a Web Host Server or even a combination of a wide variety of roles where required. With physical servers there is a tendency to try and do more with less.
The advantage of a Physical Server for a small business with limited server needs, is that the one server can perform all the tasks required for the day to day running of the business. As your business scales up in size you will have a 2nd server and 3rd and so on, the number generally corresponding with scale of the business. Each server will generally be critical to the business in some form because rarely do people sign off on implementing a new server to do something inconsequential. Inconsequential tasks are added to an existing server where it won’t conflict with something in place.
Virtual Servers:
A Virtual Server is normally one of many servers that operate upon a single physical server with each virtual server sharing the resources of the physical server between them. However an effective virtual infrastructure cannot run upon a single physical server so proper implementation of virtual servers requires the use of multiple physical servers and more than likely a device capable of providing shared storage between the physical servers. This means the starting cost of a Virtual Server solution is higher than that of a single physical server solution.
The advantage of Virtual Servers is that each server can be run upon any capable physical server and so the failure of a physical server, with a proper environment in place, means any affected servers that were sharing that physical server, can be started up seamlessly on any other available physical server. This can even be automated within most virtual infrastructure solutions which leads to near zero downtime. One of the consequences however of Virtual Servers is that because you can have multiple Virtual Servers on a physical server the temptation is to put each software product onto its own server because there is not the cost limitation of having to have one physical server for each. This is known in the industry as “server sprawl” and it is something to be avoided. While the benefits of Virtual Servers are significant, they still need to be planned and maintained effectively to ensure their continued productivity.
Cloud:

Cloud is a general term, largely expressed in marketing, to describe any server/service that is put outside your own control for someone else to maintain on your behalf. This type of solution is not new and have historically been called outsourcing, services from Application Service Providers and more going back over the last 4 years in Kenya. The Cloud terminology has gained great traction with decision makers because it sounds like a wonderful and cheap solution to remove IT considerations from a business.
My note of caution with Cloud solutions is that anyone who has used IT services will know that the quality of service varies greatly between providers and even over time, with some providers being exceptional but gradually failing to deliver sometimes after years of effective service. Cloud solutions are generally designed by the provider as a one way solution. They assume that everyone that uses them will be forever happy with them and will never want to leave and so designing or considering the process of a customer leaving is rarely addressed. Strategic use of Public Cloud, Private Cloud, Hybrid Cloud and any other Cloud term you are likely to see or hear is definitely effective and a number of Kenyan Engineers have been providing services that are considered Cloud for a number of years now. In fact they are probablyamong the most experienced Cloud providers there is in Africa. However implementing a Cloud solution is something that everyone has to go into with their eyes wide open and a clear understanding of what will be provided, who will provide, who has access to your information, is it protected from disaster (and is the provider responsible for its loss!) and ultimately can you move to more advanced services or services that suit your business better in the future that will inevitably occur.
There are several advantages and disadvantages to each option. These range from power consumption, storage requirements, maintenance, product licensing and more. This wide range of considerations also mean almost no business has the exact same needs as another and so it is important to ensure you engage someone competent in all of these options and considerations before you make any decision so that the decision you make is the right one. The cost and effort involved in reversing decisions that turn out to be wrong can be catastrophic.
There are several Kenyan engineers who are now widely versed in these solutions and implement and support every conceivable variation of them on a daily basis. If anyone would like to mail and find more on these expertise and knowledge please email sknjeri@wichita.edu or samwelkariuki@icloud.com and i will gladly assist you.May Africa stars shine beyond the so called or discussed Cloud services.Its time for africa to rise and shine.

Sunday 2 March 2014

NEW SERVICES ABOUT CLOUD COMPUTING

   Kenya is an amazing place to gather knowledge#trustMe,just mingle with the right group.Recently i just learn how to install some cloud computing services to other OS's like ubuntu and the likes-This lovely sunday,i wanna share the same with our african techno-gigs,telcom aficionados and ICT lovers:Its about SALT.
Salt is a tool which is used for remote exection, configuration management, code deployment and communication topologies. Salt competes with popular cofiguration management tools like chef and puppet. Salt claims to scale up to tens and thousands of servers. Salt is used by one of the social networking giants Linkedin for their infrastructure management.Salt has a very shallow learning curve and you can get going quickly.

Architecture:
  1. There is a master server and it connects to the agent servers (called minions) in your infrastructure.
  2. The master can run commands in the minions parallelly, it is what make salt very fast.
  3. The minions will execute the command sent by master and return it.
There are few concepts associated with salt.

Also Read:  Opscode Chef Configuration Management tool setup

Returners: Using which you can redirect the return object of executed code to any system which can accept data, like reddis, mongodb, or a PostgresSQL database.


Salt-syndic: salt syndic is an interface which lets you to control various salt masters in different data centers or different sections in an infrastructure from one centralized salt-master.

Reactor:
Reactor sit up in the master. You can configure the reactor to list to the events .When the minions fire some events to the even bus in the salt master , the reactor handles the event by taking necessary actions based up the conditions set in the reactor. For example , if Jenkins is running on one of the minions and it fires an event to master saying the build has finished, the reactor in turn handles the event and redirect to another minion to take actions based on the Jenkins successful build.

GitFS:
In salt you can git as a source repository and pull the source files to server them to minions.
In this tutorial, am goin to set the salt master in RHEL and salt minion in Ubuntu 13.04.

Setting up salt master on RHEL6:
1. Enable the EPEL repo
rpm -Uvh http://ftp.linux.ncsu.edu/pub/epel/6/i386/epel-release-6-8.noarch.rpm
2. Install the salt master package using yum
Yum install salt-master
3. Set the salt-master service to start on system boot
Chkconfig salt-master on
4. Start the salt master
Service salt-master start
Setting up salt minion on Ubuntu server:
If you want both the master and minion in one server, you can install the minion in the same server using yum command. Here am going to use a separate server for installing minion.

1. Add the salt repository
sudo add-apt-repository ppa:saltstack/salt
2. Update the repo database
apt-get update
3. Install salt minion
apt-get install salt-minion
Configuring salt Master:
By default salt master listens to post 4505 and 4506. So make sure these ports are open in Iptables and any firewall if any. If you are using AWS instance , make sure these ports are open in the security groups.

Configuring salt minion:
By default salt minion listens to 4505 and 4506 , so make these ports are opened as mentioned above.
Open the /etc/salt/minion and uncomment the master option and give your masters ip
master : ip of master 


By default you have the hostname “salt”. You can use the same name if you edit your /etc/hosts file and make an entry for your salt master with name “salt”.

Registering minion with the master:
1. Start the minion
salt-minion
2. The above command will contact the master with keys for authentication.
3. Go to salt master and issue the following command to see it has any requests for authentication from new minions.
salt-key –L
4. You will see the hostame of the minion under unauthorized keys.
5. Accept the keys using the following command
salt-key  -a  
6. Once you accept the keys from minion , it will be registered with the master and the master can now issue commands to the minion.
7. You can list the minions using the following commands.
salt-run manage.up 
salt-run manage.status 
salt-run manage.down
Testing master minion connection:
1. You can check the master minion connection using the simple salt ping test. It gives you output as "true"
salt <minion-name> test:ping
Managing Keys:
If you want to re-register a minion to the master delete the existing minion key from the master using the following command
salt-key –d minion-name
Restart the minion after deleting the key and start it again to register it with new keys. 

Salt has a GUI called Halite, which is in pre-alpha stage.

Kindly share the article and leave a comment for queries. - 

Author:Samwel Kariuki
website:www.sknjeri.wordpress.com