In 2010, with the transition to fiber-optic connectivity, Develer starts a renewal process of internal technological structure.

This process took the form a few months ago, even on internal servers, renewed in both hardware and software, leading us to move from a structure based on physical servers into a structure that operates on virtualized servers.

This step, debated and evaluated, was dictated by the attainment of the physical limit of the old hardware architecture; in fact we had 2 servers in-house (Trinity, Atlantis), which were carried out most of the necessary functions.

Trinity served as:

• Intranet
• Mail server
• NFS e Home manager
• shell server

Atlantis was our web server where we host several services, from our websites (such as better software) to customer applications.

As mentioned, the move was designed to solve most of the problems we had encountered in the old structure.

Here are some of the main reasons which justified the migration:

Hardware Performance Lock

The system as it was until a few months ago was born with Develer, when in the company orbited only 5 employees, it goes without saying that with the current "almost 30" the old server was a little bit in trouble!

The system as it was until a few months ago was born with Develer, when in the company orbited only 5 employees, this explains why with today's "almost 30" the old server was a little bit in trouble!

Client Home with NFS, in fact, could no longer climb performance, creating a real bottleneck for all client and internal applications.

Non Enterprise Hardware

Hardware that was running the whole system was very good consumer-grade hardware, which has done an excellent job, but with the disadvantage of being subject to a lot more maintenance than necessary, compared to enterprise-class hardware.

Hardware proliferation

This logistically annoying aspect could be understood as a simple choice of "aesthetics", but it is not; proliferation of patch cords, current cables, space occupied by the server, does not lead to any user benefit and therefore are not a viable option if you want to optimize resources and spaces.

Single Point of Failure

This is really easy to explain. If Trinity does it all, when Trinity goes down ... you do not work :)

The choice of virtualization

This choice was based not only on cancellation of the old problems, but also on 4 different results we are aiming for the new configuration:

Only enterprise-class hardware!

This is because we did not like the proliferation of hardware, but also because the response times for maintenance of enterprise-class hardware is extremely fast!

We currently use:

• SAN: HP P2000 G3 MSA Fibre Channel
• 2 server: HP DL380G7 (2 CPU Xeon E5630 quad-core, 24GB RAM, fibre channel card)

No more waste of resources!

With virtualization, balancing and resource sharing is a very easy goal to achieve, as opposed to the old setting.

Now we can optimize in real time the load on each server CPU, based on power demand in every moment of every service virtualized.

Easy to manage!

All virtual servers are managed remotely from the console with the advantage that you do not need to be physically present to turn off / on, use CD or DVD, we can add or remove virtual drives as we like, connect the virtual machine to another without a subnet rather than touching wires.

All management of "physical" issues are focused on two servers only.

Improving scalability and timing of service startup

This is the consequence of hitting the three previous objectives!

A more powerful hardware that can be easily managed, in real time by controlling and balancing workloads leads to improved startup times of any new online service is necessary.

Scalability is ensured by a proper sizing of servers:

• 24 GB of RAM per server can accommodate all our virtual machines on a single server; if any VMs need more resources can automatically turn on the machine less engaged.
• The dual quad-core processors on each server, provide more than adequate CPU power. VMs running on the same hardware so when a VM needs more memory or processing power it can use directly the server resource not engaged in other processes. By contrast, in the case of many separate physical servers each is limited to its CPU and memory and can not take advantage of others.
• All hardware upgrades and maintenance (memory, CPU, disks on the SAN) may be made without shutting down or put offline virtual machines and services.

Migration to the VM

The migration has led to a structure of the redundant data centers with 2 physical servers, connected with a fiber channel SAN, which manage the workload, with NFS and home run on a physical level, while all other services are virtualized 8 different VMs.

CED architecture:

The only service that has not been virtualized is coupled between the Home + NFS. This choice was made because NFS served by the VM was not able to fully exploit the speed of access to records provided by the SAN, making the service only "a little better" than the old server.

NFS and home were then mounted on the physical server, reducing any performance problem permanently.

Benefits of VM:

The new structure allows implicitly a number of considerable advantages, both in terms of performance and security management services.

Live migration with redundant servers and shared storage

The services, Virtual Machine, are kept on the server (example) A. Being a cluster (2 nodes cluster) in the event that the server had to have some hardware problem sites and the VMs are migrated on server B, the migration is "hot type", with virtually no down of the services.

The SAN is redundant, and that in feeding and even in RAID controller, making it virtually impossible for a failure by "total immobility."

To manage the synchronization of real-time data storage in a first step we evaluated the use of DRBD (http://en.wikipedia.org/wiki/DRBD). We found insufficient evidence made ​​by your performance so we decided to use the SAN.

Performance Tuning

As said, the management of users' home was an important part in the selection of the new solution. The choice of shared SAN is motivated by the possibility to scale and optimize their performance compared to using DRBD.

The performances are guaranteed by SAS (serial attached SCSI) dual port to 15000 RPM. The rather high throughput is maintained by connecting Fibre Channel SAN <-> Server 4Gbit.

Superior reliability

Discs server-grade drives with an MTBF of more than consumers. Redundancy of all components (RAID disks, 2 controllers, 2 power supplies, 2 cache, 2 fiber connections). A confidence level impossible to achieve with consumer components.

Versatility and efficiency in storage management

All virtual disks are on SAN and configuration via the web management interface is very flexible (ability to take snapshots of data, copying, resize the virtual disks, load distribution of I / O across several disk groups as needed of the various virtual machines).

Used Software

Here's what we chose:

• Ubuntu server 11.04 (Natty Narwhal)
• Qemu + KVM + libvirt
• Pacemaker e Corosync (HA)

Why KVM?

KVM has shown better performance (about 20%) on new hardware compared to a solution like Xen, although this remains a more mature and has more features than the KVM

In addition XEN Hypervisor is actually very light, but the main system is a VM, and of our requirements was to run NFS on actual hardware and not on VM.

Conclusion ...

Speaking of optimizations, the problem to solve at this point remains the wired network, office wired gigabit limit begins to be compared with the performance of 4Gb fiber channel connection between the servers and the SAN:)

As soon as possible to put online some performance tests that have helped us to choose between the various solutions (SAN DRDB vs. Xen vs. KVM as well) as well as some benchmarks before and after treatment :)