Monday, 16 March 2015

Concepts of VZ container[with templates]

EZ templates are part and parcel of the Parallels Virtuozzo Containers philosophy because they  provide a way of sharing resources among lots of Containers, thus enabling huge savings in terms of disk space and memory. For example, when you install and cache an OS template on the Hardware Node, Parallels Virtuozzo Containers creates the  /vz/template/<name_of_the_OS> directory containing all the OS files that can be shared among Containers. When a Container based on this template is created, it contains only symlinks
to the OS template files. These symlinks occupy very little space on the hard disk. They are situated in the so-called private area of the Container. The corresponding directory is /vz/private/<CT_ID>.
The private area of a Container contains not only symlinks to the necessary template files, but also the copy-on-write area of the Container (the area for storing the  information about those changes that the Container makes to the template files; this information  pertains only to the given directory) and all the private Container files. When the Container is started, this private area is mounted as Virtuozzo File System (VZFS) to the /vz/root/<CT_ID> directory. This directory is seen as the root directory from within the Container. And, which is the pivot of it all, thanks to the VZFS, the symlinks of the Container private area are seen as real files there.

Thus, the most important directories in the /vz partition are the following:
/vz/template - contains OS and application files shared among Containers;
/vz/private - contains VZFS symlinks to template files;
/vz/root - contains Container mounted symlinks and all other Container files.

The relation of these directories may be represented as below:
/vz/template (real files) --> /vz/private (symlinks) --> /vz/root (symlinks seen as real files in / for the Container).

 1 Any EZ template should be first installed on the Hardware Node. The vzpkg install template command enables you to install OS and application EZ templates on the Node.

2 The EZ template should be cached by using the vzpkg create cache command. This step is required for OS EZ templates only. As a result of the vzpkg create cache execution, the necessary packages included in the OS EZ template are downloaded from the network repository, installed in the /vz/template/<os_name>/<os_version> directory on the Hardware Node, and a gzipped tarball for the OS EZ template is created and put to the /vz/template/cache directory.

3 Either a new Container is created on the basis of the cached OS EZ template with the vzctl create command or an application EZ template is added to any number of Containers by using the vzpkg install command. In the latter case, the necessary application files are first downloaded from the network repository and installed on the Hardware Node and then the VZFS links to the installed files are created and added to the Container private area.

4 An obsolete EZ template applied to the corresponding Container can be updated by using the vzpkg update command.

5 Any EZ template excluding OS EZ templates can be removed from the Container with the vzpkg remove command.

 6 An EZ template that is not used by any Container may be completely removed from the Hardware Node with the vzpkg remove template command.

Thursday, 12 March 2015

Mysqli is not working properly

In plesk server, I have installed the php 5.6 as secondary php.
Then if I have try to use "mysqli" dbtype in Joomla site, I got error such as database connection error.

Cause:
-----------
It seems mysqli uses mysqlnd API in secondary php,

mysqli
Client API library version => mysqlnd 5.0.11-dev - 20120503 - $Id: 3c688b6bbc30d36af3ac34fdd4b7b5b787fe5555 $
mysqli.allow_local_infile => On => On
mysqli.allow_persistent => On => On
mysqli.default_host => no value => no value
mysqli.default_port => 3306 => 3306
mysqli.default_pw => no value => no value
mysqli.default_socket => no value => no value
mysqli.default_user => no value => no value
mysqli.max_links => Unlimited => Unlimited
mysqli.max_persistent => Unlimited => Unlimited
mysqli.reconnect => Off => Off
mysqli.rollback_on_cached_plink => Off => Off

By default mysqli uses mysql API in main php,

mysqli
MYSQLI_SOCKET => /var/run/mysqld/mysqld.sock
mysqli.allow_local_infile => On => On
mysqli.allow_persistent => On => On
mysqli.default_host => no value => no value
mysqli.default_port => 3306 => 3306
mysqli.default_pw => no value => no value
mysqli.default_socket => no value => no value
mysqli.default_user => no value => no value
mysqli.max_links => Unlimited => Unlimited
mysqli.max_persistent => Unlimited => Unlimited
mysqli.reconnect => Off => Off

Solution:
--------------
I suspect it might tried to using mysqlnd, Hence I changed the value from
mysqli.default_socket = " " to mysqli.default_socket = /var/run/mysqld/mysqld.sock in respective php.ini[Used secondary php 5.6 php.ini here].
By default if we didn't give anything in this value, it automatically takes the default socket. Here I think mysqli tried to take mysqlnd socket. So I manually changed it to mysql socket.
Then the issue was fixed.

Sunday, 8 March 2015

LVM Snapshot Process

Reference: http://www.clevernetsystems.com/tag/cow/

This article explains how LVM snapshots work and what the advantage of read/write snapshots is.
We will go through a simple example to illustrate our explanation.
First, create a dummy device that we will initialize as a PV:
# dd if=/dev/zero of=dummydevice bs=8192 count=131072
# losetup /dev/loop0 dummydevice
# pvcreate /dev/loop0
# pvs
PV VG Fmt Attr PSize PFree
/dev/loop0 lvm2 a-- 1.00g 1.00g
We now have a 1GB LVM2 Physical Volume.
# vgcreate vg0
# vgs
VG #PV #LV #SN Attr VSize VFree
vg0 1 0 0 wz--n- 1020.00m 1020.00m
# lvcreate -n lv0 -l 100 vg0
# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
lv0 vg0 -wi-a---- 400.00m
We now have a Volume Group vg0 and a 400MB Logical Volume lv0. Let’s see what our device mapper looks like
# dmsetup table
vg0-lv0: 0 819200 linear 7:0 2048
We have a single device vg0-lv0, as expected.
Let’s take a snapshot of our Logical Volume:
# lvcreate -s -n snap1 -l 30 /dev/vg0/lv0
# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
lv0 vg0 owi-a-s-- 400.00m
snap1 vg0 swi-a-s-- 120.00m lv0 0.00
We’ve created a 30 extents (120MB) snapshot of lv0 called snap1.
Let’s take a look at our device mapper:
# dmsetup table
vg0-lv0-real: 0 819200 linear 7:0 2048
vg0-snap1-cow: 0 245760 linear 7:0 821248
vg0-lv0: 0 819200 snapshot-origin 252:2
vg0-snap1: 0 819200 snapshot 252:2 252:3 P 8
This is interesting. We’d expect to see two devices. Instead, we have four. Let’s draw the dependencies:


lvm snapshotsLVM snapshots explained
We can see that LVM renamed our vg0-lv0 device as vg0-lv0-real and created a new vg0-lv0 device. The user has now transparently switched to using vg0-lv0.
A new device named vg0-snap1-cow is the device of size 30 extents (120MB) that will hold the contents of the snapshot.
A new device named vg0-snap1 is the device that the user will interact with.
Reading from the original volume
The user reads from vg0-lv0. The request is forwarded and the user retrieves data from vg0-lv0-real.
Writing to the original volume
The user writes to vg0-lv0. The original data is first copied from vg0-lv0-real to vg0-snap1-cow (This is why it’s called COW, Copy On Write). Then the new data is written to vg0-lv0-real. If the user writes again to vg0-lv0, modifying data that has already been copied to vg0-snap1-cow, the data from vg0-lv0-real is simply overwritten. The data on vg0-snap1-cow remains the data that was valid at the time of the creation of the snapshot.
Reading from the snapshot
When the user reads data from vg0-snap1, a lookup is done on vg0-snap1-cow to see if that particular piece of data has been copied from vg0-lv0-real to vg0-snap1-cow. If that is the case, the value from vg0-snap1-cow is returned. Otherwise, the data from vg0-lv0-real is returned. The user effectively sees the data that was valid at the time of creation of the snapshot.
A few important things to note:
  • The snapshot is empty at creation, whatever size it is. This means that the creation of a snapshot is immediate and invisible to the user.
  • The snapshot will hold a copy of the original data, as the original data is modified. This means that the snapshot will grow over time. Therefore, it is not necessary to make a snapshot as big as the original volume. The snapshot should be big enough to hold the amount of data that is expected to be modified over the time of existence of the snapshot. Creating a snapshot bigger than the original volume is useless and creating a snapshot as big as the original volume will ensure that all data on the original volume can be copied over to the snapshot.
  • If a snapshot is not big enough to hold all the modified data of the original volume, the snapshot is removed and suddenly disappears from the system, with all the consequences of removing a mounted device from a live system.
  • A volume that has one or more snapshots will provide much less I/O performance. Remove the snapshot as soon as you’re done with it.
Writing to the snapshot
With LVM2, as opposed to LVM1, the snapshot is read-write[In LVM1, the snapshot is read-only].
When the user writes to vg0-snap1, the data on vg0-snap1-cow is modified. In reality, what happens is that the a lookup is done to see if the corresponding data on vg0-lv0-real has already been copied to vg0-snap1-cow. If not, a copy is done from vg0-lv0-real to vg0-snap1-cow and then overwritten with the data the user is trying to write to vg0-snap1. This is because the granularity of the data copy process from vg0-lv0-real to vg0-snap1-cow might be bigger than the data the user is trying to modify. Let’s imagine that data is being copied from vg0-lv0-real to vg0-snap1-cow in chunks of 8KB and the user wants to modify 1KB of data. The whole chunk is copied over to the snapshot first. Then the 1KB are modified.
A second write to the same data will result in simply overwriting data in vg0-snap1-cow.
Removing an LVM snapshot
The following command will remove the snapshot:
# lvremove vg0/snap1
  • This operation is very fast because LVM will simply destroy vg0-snap1-cow, vg0-lv0 and vg0-snap1, and rename vg0-lv0-real to vg0-lv0.
  • All data that has eventually been written to the snapshot (through vg0-snap1) is LOST.
Merging a snapshot
The following command will merge the snapshot:
# lvconvert --merge vg0/snap1
Merging of volume snap1 started.
lv0: Merged: 100.0%
Merge of snapshot into logical volume lv0 has finished.
Logical volume "snap1" successfully removed
  • The merge will start immediately if the filesystems in the original volume and in the snapshot are unmounted (i.e. if the volumes are not in use), otherwise the merge will start as soon as both filesystems are unmounted and one of the volumes is activated. This means that if a merge of the root filesystem is planned, it will happen after a reboot, as soon as the original volume is activated.
  • This operation can take time, because data needs to be copied from the snapshot to the original volume.
  • As soon as the merge begins, any read-write operation to the original volume is transparently redirected to the snapshot that is in the process of being merged. Therefore, the operation is transparent to the user who thinks he’s using the merged volume. This means that as soon as the merge begins, users interact with a volume that contains the data at the time of the creation of the snapshot (+ data that has eventually been written to the snapshot since then).