分类： LINUX
2010-03-02 15:22:44
With openQRM hardware is just used as "computing resource" which can
be replaced easily without the need to adapt or reconfigure the server
(-image) at all.
硬件故障不会影响到软件和操作系统
In 4.1 we just added KVM to our supported virtualization technologies
so now VMware, Xen, KVM and
Linux-VServer vms can be managed
transparently via openQRM. openQRM seamlessly support P2V (physical to
virtual), V2P (virtual to physical) AND V2V (virtual to virtual)
migration. This mean server appliances can not only move from physical
to virtual (and back) easily but also that they can be migrated from
virtualization technology A to virtualization technology B without any
hassle.
Nagios is known to be a great system and service monitoring tool .... but it's quite difficult to configure it. In openQRM 4.1 we just developed a completely automatic configuration of Nagios via "nmap2nagios-ng" which maps the entire openQRM-network and creates (or updates) the Nagios config for it (all systems, all available services).
Deployed some new servers ? with a single mouse click you will have them in the Nagios monitor.
You can have e.g. 10 custom HA-servers which normally would need
another 10 custom stand-by systems. With openQRM you can make them all
just use 1 (or more) stand-by systems 减少热备机器
-> this can save you 9 servers idling around --> perfect for Green IT !
... and there is more fun with HA !
You can just save ALL your stand-by servers and just bring up a
virtual-machine as stand-by. In case of problems HA-appliances will then
fail-over from physical to virtual. You can also fail-over from
virtualization technology A to technology B (e.g. from KVM to VMware
vm's)
To get started quick and easy openQRM 4.1 now provides ready-made and
known-to-work server-images for Debian, Ubuntu, CentOS and openSuse.
Therefore we added an image-shelf plugin which allows the
systemadministrator to fetch servers easily via the web-interface.
Public or custom image-shelf servers can be used, meaning you can either
fetch server-images from our public image-shelf server or provide
your own image-shelf server with custom images.
We asked ourself "what is linux ?", it is the kernel, an initrd, some
modules and a root-filesystem. Those are all "just" files ..... so we
should treat them like files by putting and managing them on modern
storage-servers. Then can we also benefit from logical volume management
(e.g. LVM2, NetApp flexiclone etc.) to ultra fast clone existing
server-images via snap-shotting. So in case you want to deploy 10 new
server
openQRM will create 10 snapshots of an existing, known-to-work
server-image and deploy those clones to the resources. Takes a second
...
Another benefit of this concept is that there is a single place for backup/restore, there were it should be, on the storage-server itself so you can use its cloning/snap-shot features again to create hot-backups from your servers without service interruption.
openQRM 4.1 supports the following storage-server types :
Deployment in openQRM is completely transparent and plug-able. In detail this means we made the step of "mounting the rootfs" plug-able so you can basically boot-up from any storage-device you want by adding a small plugin for it e.g. one could write a "gmailfs-storage" plugin which takes care to mount a servers root-filessystem via gmailfs, just because it can be done ;)
Another advantage of openQRM is that it then can transform server-images from type A to type B e.g. you can deploy an appliance which will get a pre-defined server-image from an nfs-server and dumps this to itsl ocal-disk, then it will just continue boot-up from its local-disk. You can also grab an image from a local disk and e.g. transfer it to an Iscsi-Lun and so on ....
Since the deployment is so generic in openQRM 4.x we basically support any combination of image transfer and transform. If it is a root-filesystem, we can boot it, .... either on real hardware or within some virtual machine, you decide.
openQRM 4.x comes with a solid support for different linux distribution like Debian, Ubuntu, CentOS and openSuse. A single openQRM server can manage the provisioning of servers from those different linux distributions seamlessly.
