Monday, 29 September 2014

Concepts of QCOW2 & RAW format

QCOW2 Formatted Virtual Machine Storage

QCOW2 is a storage format for virtual machine disk images. QCOW stands for QEMU copy on write. T he QCOW2 format decouples the physical storage layer from the virtual layer by adding  a mapping between logical and physical blocks. Each logical block is mapped to its physical offset, which enables storage over-comittment and virtual machine snapshots, where each QCOW volume only represents changes made to an underlying disk image.
T he initial mapping points all logical blocks to the offsets in the backing file or volume. When a virtual machine writes data to a QCOW2 volume after a snapshot, the relevant block is read from the backing volume, modified with the new information and written into a new snapshot QCOW2 volume. T hen the map is updated to point to the new place.

RAW
T he RAW storage format has a performance advantage over QCOW2 in that no formatting is applied to virtual machine disk images stored in the RAW format. Virtual machine data operations on disk images stored in RAW format require no additional work from hosts. When a virtual machine writes data to a given offset in its virtual disk, the I/O is written to the same offset on the backing file or logical volume.
Raw format requires that the entire space of the defined image be preallocated unless using externally managed thin provisioned LUNs from a storage array.

Friday, 26 September 2014

PHP Fatal error: Class 'JFactory' not found

I have faced this issue in Joomla site and searched the forums but none of the forums including joomla did not give solution for me.
They simply suggest to check joomla version, php version compatibility and php extensions.
Finally I have fixed the issue.


Issue:-
---------
 [26-Sep-2014 18:11:29 Europe/Berlin] PHP Fatal error: Class 'JFactory' not found in /home/test/public_html/index.php on line 31

Cause & Solution:-
-----------------------
In my case, it seems file which gives the class JFactory was missed.

/home/test/public_html/libraries/joomla/factory.php --->Core file for Joomla.

Simply restore that file under proper path to fix the issue.

Friday, 19 September 2014

Thursday, 11 September 2014

Synchronization tools

1.Lsyncd - Live Syncing (Mirror) Daemon[Directory level]
2.DRBD.[block device level]
3. GlusterFS and BindFS use a FUSE-Filesystem to interject kernel/userspace filesystem events. 

Reference:
-----------------
https://code.google.com/p/lsyncd/
http://configure.systems/glusterfs-and-why-you-should-consider-it/

GlusterFS would actually mitigate and simply so much more of that. There would be no need for a Load Balancer, no need for a special script to promote, demote the content servers, nothing, not even to replicate the data between the servers!
Basically, you can create two or more servers, install GlusterFS on each of the servers, have node all of the nodes probe the master node, then you would create the volume. Easy.
Once that’s done, one your actual web nodes, where you have Apache, PHP, and again Varnish installed, you would install GlusterFS, add the correct line to the /etc/fstab, and you’re set. Within that line, you can even add a failover server in case the primary goes down! Say what? Not only that, when it comes back up, it can self-heal to ensure consistency across all servers again.
Adding more servers to the GlusterFS environment is pretty simple too, couple commands and you’re good to go. All of this could even be automated.
There are some other comparable options but GlusterFS seems to be a very viable option, one that I use on this servers configuration. I’m not a big site, nor do I serve tens of thousands of users. However, I’m completely ready to scale at the drop of a hammer if need be. Both from a saved image and from a completely orchestrated manner with Ansible. The less moving parts, the better. Keep everything dedicated one set of resources and you’ll be building for success.

Wednesday, 10 September 2014

Saturday, 6 September 2014