DATA DEDUPLICATION

Data deduplication technology has gained rapid acceptance in the IT industry over the past several years for its ability to dramatically reduce the amount of backup data stored byeliminating redundant data. In its simplest terms, datadeduplication maximizes storage utilization while allowingorganizations to retain more backup data on disk for longer periods of time. This tremendously improves the efficiency ofdisk-based backup, lowering storage costs and changing theway data is protected. 

 

Although data deduplication solutions vary in terms of howdeduplication is accomplished, in general, data deduplicationworks by comparing new data with existing data from previous backup or archiving jobs, and eliminating there dundancies. Because only unique blocks are transferred,replication bandwidth requirements are reduced.

Debian GNU/Hurd 2013 release.

It is with huge pleasure that the Debian GNU/Hurd team announces the release of Debian GNU/Hurd 2013. This is a snapshot of Debian "sid" at the time of the Debian "wheezy" release (May 2013), so it is mostly based on the same sources. It is not an official Debian release, but it is an official Debian GNU/Hurd port release.

The installation ISO images can be downloaded from Debian Ports in the usual three Debian flavors: NETINST, CD, DVD. Besides the friendly Debian installer, a pre-installed disk image is also available, making it even easier to try Debian GNU/Hurd.

Debian GNU/Hurd is currently available for the i386 architecture with more than 10.000 software packages available (more than 75% of the Debian archive, and more to come!).

Virtualization

The virtualization layer is implemented by the VMM and is software that runs in a layer between the VMkernel and one or more VMs. It provides the VM abstraction to the guest operating systems.

It is through the VMM that the VM leverages key technologies in the VMkernel. The VMM is part of the VMkernel and is provided for each VM.

The vSphere VMM manages CPU, memory, and input/output, or I/O, device virtualization by implementing software virtualization, hardware virtualization, or paravirtualization techniques.

Software virtualization is an approach in which the hypervisor uses binary translation technology to provide virtualization of CPU and memory for the guest operating systems.

Hardware virtualization is a technique in which hardware capabilities of current CPUs are exploited to provide virtualization of CPU and memory.

Paravirtualization is a virtualization approach that exports a modified hardware abstraction that requires operating systems to be explicitly modified and ported to run. VMware uses paravirtualization to optimize the performance of certain drivers, for example, Small Computer Systems Interface, or SCSI, and network drivers.

New Features in Linux Kernel 3.9

Ten weeks to the day after the arrival of version 3.8, Linux creator Linus Torvalds on Monday released version 3.9 of the Linux kernel.
“This week has been very quiet, which makes me much more comfortable doing the final 3.9 release, so I guess the last -rc8 ended up working,” wrote Torvalds in the announcement email early Monday. “Because not only aren't there very many commits here, even the ones that made it really are tiny and not pretty obscure and not very interesting.”

Linus Torvalds on Monday released version 3.9 of the Linux kernel.

That's certainly not to say that this new kernel release doesn't include a number of interesting features overall, however – quite the contrary, in fact. Here's a quick look at some of the highlights. 1. SSD Caching
It's always nice to see new features that enable faster performance, and one such example is Linux 3.9's addition of a device mapper target (dm-cache) that enables the use of speedy devices such as solid-state drives (SSDs) as a cache for slower devices such as rotating hard disks.  “Different 'policy' plugins can be used to change the algorithms used to select which blocks are promoted, demoted, cleaned etc.,” explains the changelog on KernelNewbies.org. “It supports writeback and writethrough modes.”
2. Expanded Architecture Support
Broadened support is another change that's pretty much always welcome, and Linux 3.9 actually adds two new architectures to the list of those supported. Specifically, this new release brings the Linux kernel port to the ARC700 processor family (750D and 770D) from Synopsys as well as the Meta ATP (Meta 1) and HTP (Meta 2) processor cores from Imagination. Meta cores can be found in many digital radios, while the ARC700 family is commonly embedded in SoCs in TV set-top boxes and digital media players.
3. Better Power Efficiency
Thanks to the inclusion of the Intel PowerClamp driver, which performs synchronized idle injection across all online CPUs, Linux 3.9 also offers improved power efficiency in terms of performance per watt.
4. Chromebook Support
Particularly useful for Chromebook owners yearning to get their favorite distro up and running on their machine, meanwhile, is that Linux 3.9 adds full support for “all the devices present in the Chrome laptops sold by many companies,” as KernelNewbies puts it.
5. Another Boost for ARM
Linux's support for ARM has improved considerably over the past few releases, and kernel 3.9 brings a key improvement in the form of support for the KVM virtualization system in the ARM architecture port. As KernelNewbies notes, “this brings virtualization capabilities to the Linux ARM ecosystem.”
6. Android Developer Support
Finally, targeting Android developers this time, Linux 3.9 adds support for the “Goldfish” virtualized platform that's part of the Android development environment. Essentially, that means it's now possible to develop for Android with “out-of-the-box” kernels.

How to write Redhat cloned distro initialization scripts with Upstart

On Linux systems, initialization (init) scripts manage the state of system services during system startup and shutdown. When the system goes through its runlevels, the System V init system starts and stops services as configured. While this tried-and-true technology has been around since the dawn of Unix, you can now create modern and efficient CentOS 6 init scripts by using Upstart, an event-based replacement for System V init.
Until its latest release, CentOS used the System V init system by default. SysV init scripts are simple and reliable, and guarantee a certain order of starting and stopping.
Starting with version 6, however, CentOS has turned to a new and better init system – Upstart. Upstart is faster than System V init because it starts services simultaneously rather than one by one in a certain order. Upstart is also more flexible and robust, because it is event-based. Upstart generates events at various times, including while going through the system runlevels, similar to the SysV init system. However, Upstart may also generate custom events. For example, with Upstart you can generate an event that requires certain services to be started, regardless of the runlevel. And Upstart not only generates events, it also handles them – so, for example, when it acknowledges the event for starting a service it will do so. This event-based behavior is robust and fast.
Upstart supports SysV init scripts for compatibility reasons; most service init scripts in CentOS 6 continue to be SysV-based. You might someday have to create an init script yourself if you write custom software. If you do, you should write your new init scripts with Upstart in mind so you can benefit from the new init system's faster performance and additional features.

Beginning the Upstart init script

Upstart keeps init scripts in the /etc/init/ directory. A script's name should correspond to the name of the service or job it controls, with a .conf extension. The init script for the Tomcat service, for example, should be named /etc/init/tomcat.conf.
Like SysV init scripts, Upstart init scripts are regular Bash scripts, but extended with some Upstart-specific directives, which are called stanzas in Upstart. In SysV init scripts you commonly see the line . /etc/init.d/functions, which provides access to additional necessary SysV functions. Upstart scripts are more sophisticated and complete; you don't have to include any additional functions or libraries.
Just as in any Bash script, comments in Upstart scripts start with #. Put descriptive comments at the beginning of each script to explain its purpose, and in other places where the code may need explanation. You can use two special stanzas, author and description, for documentation.

Defining when a service starts

After the introductory comments you can define when a service should start and stop using the special stanzas stop on and start on. These two stanzas can be used with a recognized Upstart event such as when the system enters a runlevel.
Usually administrators configure service jobs to start and stop with the server. By convention, in CentOS you should configure a service job to start at runlevels 2, 3, 4, and 5 and stop at runlevels 0, 1, and 6. In an Upstart init script this is written like this:

start on runlevel [2345]
stop on runlevel [06]

This instructs Upstart to start and stop the service whenever the system enters the runlevel in brackets.
Upstart also lets you start or stop services based on other types of events, such as the starting or stopping of other services. For example, suppose you have an Apache web server integrated with a Varnish caching web server, as described in the article Varnish improves web performance and security. In such a scenario you should make sure that Varnish starts whenever Apache starts, so the configuration stanza for Varnish should look like:

start on starting httpd
stop on stopped httpd

The latter stanza is an unique feature of Upstart; Upstart init scripts can stop services at the same time as other services are stopped, while SysV init scripts depend solely on runlevels.
Another difference is that you configure SysV init scripts when to start and stop by placing symlinks to them in the corresponding runlevels' directories in /etc/rcX.d/, where X is the runlevel number. The command chkconfig does this automatically for you in CentOS. While chkconfig continues to manage most of the init scripts in CentOS 6, it does not work with Upstart, and you cannot manage Upstart jobs with it.

Preparing for an Upstart job

To prepare and customize your environment for an Upstart service job you can use a few additional parameters, each on a new line in the job's .conf file:

• respawn – When you use this parameter the service process will be restarted if it dies unexpectedly. Without this Upstart parameter you might have to write a dedicated wrapper program to start a service and ensure its proper and constant operation, such as mysqld_safe for starting MySQL.
• expect fork – Every service job should be expected to fork in as a background process. When you specify this parameter Upstart obtains the new process's PID, which it can use later to send signals to it, such as to shut down or reload configuration.
• kill timeout [seconds] – This is the number of seconds before the process may be forcibly killed. You should specify enough time (say, 120 seconds) so that interruption-sensitive services such as MySQL are able to complete any pending operations and shut down safely.

You can also adjust a few Bash variables in the job's .conf file. For example, you can configure the umask (permissions) with which new files will be created. A secure choice is umask 007, which means that new files will be created with restrictive permissions 770, which allow only the user itself and the members of its user group to manipulate the newly created files.
A special Upstart stanza pre-start allows you to specify a command or inline script to be run right before Upstart actually starts the job. This stanza is suitable for specifying any sanity checks, such the existence of a necessary file. You may also define prerequisite tasks, such as cleaning of the caching directory of a caching proxy. If the pre-start procedure fails – that is, if it exits with a code other than zero – then the whole job fails and the service is not started.
To see how this works, here's a pre-start directive to remove PHP accelerator eAccelerator's previously cached files, as you would want to do when eAccelerator is integrated with Apache: pre-start exec rm /var/cache/eaccelerator/* -rf. A longer example with a whole inline script looks like:

pre-start script
    # check if Apache's binary is executable or fail 
    [ -x /usr/sbin/httpd ]
    # clear the /tmp directory from old sessions
    rm /tmp/sess_*
end script

Several other stanzas are similar to the pre-start stanza:

• post-start – specifies a procedure to run after starting the service. This is usually useful for complex services that may need additional attention after startup, such as MySQL.
• pre-stop – specifies actions used in preparing for the service shutdown. It is rarely used.
• post-stop – may be regarded as an alternative to the pre-start stanza; in some cases it makes more sense to take some actions right after service shutdown instead of waiting for its next start.

Configuring the Upstart start command or script

Once you've configured your environment, the last thing you must do is define the job's command or script using the stanzas script ... end script to write a regular Bash script inline, or just exec to simply execute a command with arguments. Here's an example that uses the script stanza for the rsyslog service in the rsyslog.conf file:

script
    . /etc/default/rsyslog
    exec rsyslogd $SYSLOGD_OPTIONS
end script

The above directive first sources (includes) the content of the file /etc/sysconfig/rsyslog, where the variable SYSLOGD_OPTIONS is defined. This variable is then used to start the rsyslogd service. This is a convenient way to start a service that requires complex or custom configuration, and it's why such script stanzas are suitable for services such as MySQL or Apache.
Alternatively, the exec stanza lets you specify an executable file and any additional arguments it may need. It's suitable for simpler services; for example, you can start the CUPS daemon with the directive exec /usr/sbin/cupsd -F.

How Upstart stops and reloads services

If you're familiar with SysV init scripts, you may wonder how you configure the commands to stop a service or reload its configuration. The answer is that you don't have to; with Upstart you only configure the start command for a service. When Upstart starts a service it keeps track of its PID and the PIDs of the process forks. When Upstart later needs to shut down a service, it does so with the native Unix signals. Upstart first sends a PID the SIGTERM signal to gracefully shut it down. If the process ignores SIGTERM, Upstart sends SIGKILL to forcibly kill it. Similarly, when the configuration needs to be reloaded, Upstart sends the SIGHUP signal. Upstart's simple architecture removes the needs to specify procedures for stopping, restarting, and reloading a service, though if the shutdown procedure for a service requires more than just sending SIGHUP or SIGTERM signals, you can use the pre-stop and post-stop stanzas.
One last and important difference between Upstart and SysV inits is how you manually start and stop jobs. Upstart works with the command /sbin/initctl, the init daemon control tool. It accepts as a first argument stop, start, restart, or reload, and changes the state of the service correspondingly. The second argument is the name of the service. For example, to start MySQL's Upstart job manually you would run the command initctl start mysqld.

OpenStack 'Grizzly' 2013.1 release.

Roughly six months after the launch of its “Folsom” release last fall, OpenStack on Thursday unveiled version 2013.1 “Grizzly,” the seventh and latest release of the open source software for building public, private and hybrid clouds.

More than 500 contributors made 7,620 updates in the OpenStack "Grizzly" release.

More than 500 contributors made 7,620 updates in this new release, which, “more than any before it, was driven by users who have been running OpenStack in production for the past year (or more) and have asked for broader support for the compute, storage and networking technologies they trust and even greater scale and ease of operations,” explained Mark Collier, chief operating officer at the OpenStack Foundation, in a blog post announcing the new software. Best Buy, Bloomberg, NSA, Cisco WebEx, Comcast, CERN, HP, NeCTAR, PayPal, Rackspace and Samsung are among the companies using OpenStack in production.
Developers who contributed to this release came from more than 45 companies, including Red Hat, Rackspace, IBM, HP, Nebula, Intel, eNovance, Canonical, VMware, Cloudscaling, DreamHost and SINA.

'Support for Security Groups'

Seven integrated projects make up OpenStack, each with source code now publicly available: Compute ("Nova"), Object Storage ("Swift"), Image Service ("Glance"), Networking ("Quantum"), Block Storage ("Cinder"), Identity ("Keystone") and Dashboard ("Horizon").      
More than 200 new features are included in this Grizzly release, and some 1,900 bugs were fixed. In anticipation of the launch, Linux.com spoke earlier this week with Thierry Carrez, release manager for the project, to hear about some of the highlights.
“Personally, my favorite key features for this release would be in OpenStack Compute (Nova): introduction of the 'Cells' deployment model for massive scale, and isolation of the compute nodes from the rest of the system for better security ('no-db-compute'),” Carrez began. “I also like how OpenStack Networking introduced support for security groups, as well as a load-balancing-as-a-service feature.”
Meanwhile, “I would also mention how OpenStack Block Storage (Cinder) managed to add a large number of storage drivers from all of the storage industry,” he told Linux.com. Ten new drivers were added, in fact, including Ceph/RBD, Coraid, EMC, Hewlett-Packard, Huawei, IBM, NetApp, Red Hat/Gluster, SolidFire and Zadara.
Finally, “the general drive towards more reuse of code across the various OpenStack projects (through the introduction of the common 'Oslo' libraries) is also worth mentioning,” Carrez said.

Cross-Origin Resource Sharing 

Other highlights of the new release include significant improvements in virtualization management on the Compute side, with full support for ESX, KVM, XEN and Hyper-V. Quotas were added to the Object Storage system, meanwhile, as was cross-origin resource sharing (CORS), enabling browsers to “talk directly to back-end storage environments,” Collier noted.
For Networking, Grizzly aims to achieve greater scale and higher availability by distributing L3/L4 and dynamic host configuration protocol (DHCP) services across multiple servers. New plug-ins were also added from Big Switch, Hyper-V, PlumGrid, Brocade and Midonet.
The Grizzly Dashboard, meanwhile, is backwards-compatible with the Folsom release.

vCloud Director : vSphere enter to maintenance mode

• System-> Manage & Monitor
• vSphere Resources -> Hosts

1. Find the host you need to place in to maintenance mode, right click and select Disable Host.
2.  At that point, the status will turn from a green circle with a check, to a red circle.
3. Right click on the host again and select Redeploy All VMs.
4. The ESXi host will go in to maintenance mode in the vCenter server and evacuate all virtual machines as usual.
5. (Optional!) If you see vsla errors (such as the screenshot), issues with deleting vApps, Unprepare the host which removes the vCloud agent from ESXi
6. (Optional!) Prepare the host for vCloud by pushing the vCloud agent to ESXi
7. When maintenance is complete, right click and Enable Host.
8. And your work is complete!