Monday, March 3, 2014

How To Backup ESXi Configuration – The Missing Piece

How do I Backup my ESXi USB Key?” Other than ripping the USB key out of a production machine… how was the user to do this? Well, vMA and the vCLI provide a method for this:

Backing up your ESXi Configuration:

To backup your ESXi configuration you’ll be using the vicfg-cfgbackup.pl command as follows:
  • Download either the vMA or vCLI
  • Launch vicfg-cfgbackup.pl:
    C:\Program Files\VMware\VMware vSphere CLI\bin>vicfg-cfgbackup.pl –save –server 192.168.15.253 –username root –password password backup.bak
  • Note: The backup will be stored relative to your user “AppData” path:
    C:\Users\Username\AppData\Local\VirtualStore\

Restoring your ESXi Configuration:

Restoring your ESXi config can be done after you have the host up and responding over the network again by using the following:
C:\Program Files\VMware\VMware vSphere CLI\bin>vicfg-cfgbackup.pl –load –server 192.168.15.253 –username root –password password backup.bak
Note: You will be asked to reboot the host on restore.
Backing  up multiple hosts! – There is a script to backup multiple ESXi hosts on the VMware communities site here. Also in PowerCLI here!

Tuesday, January 21, 2014

3PAR StoreServ Zoning Best Practice Guide

Original text: http://vmfocus.com/2013/08/22/3par-storeserv-zoning-best-practice-guide/

This is an excellent guide which has been written by Gareth Hogarth who has recently implemented a 3PAR StoreServ and was concerned about the lack of information from HP in relation to zoning.  Being a ‘stand up guy’ Gareth decided to perform a lot of research and has put together the ’3PAR StoreServ Zoning Best Practice Guide’ below.
This article focuses on zoning best practices for the StoreServ 7400 (4 node array), but can also be applied to all StoreServ models including the StoreServ 10800 8-node monster.
3PAR StoreServ Zoning Best Practice Guide
Having worked on a few of these, I found that a single document on StoreServ zoning BP doesn’t really exist. There also appears to be conflicting arguments on whether to use Single Initiator – Multiple Target zoning or Single Initiator – Single Target zoning. The information herein can be used as a guideline for all 3PAR supported host presentation types (VMware, Windows, HPUX, Oracle Linux, Solaris etc…).
Disclaimer:  Please note that this is based on my investigation, engaging with HP Storage Architects and Implementation Engineers. Several support cases were opened in order to gain a better understanding of what is & isn’t supported. HP recommendations change all the time, therefore it’s always best to speak with HP or your fabric vendor to ensure you are following latest guidelines or if you need further clarification.
Right, let’s start off with Fabric Connectivity
In terms of host connectivity options the StoreServ 7000 (specifically the 7400) provides us with the following:
  • 4x built-in 8 Gb/s Fibre Channel ports per node pair.
  • Optional 8 Gb/s Quad Port Fibre Channel HBA (Host Bus Adapter) per node (we will be focusing on this configuration option).
  • Optional 10 Gb/s Dual Port FCOE (Fibre Channel over Ethernet) converged network adapter per node.
StoreServ target ports are identified in the following manner Node:Slot:Port.
StoreServ target ports located on the on-board HBA’s will always assume the slot identity of 1, respectively StoreServ targets ports located on the optional expansion slot will always assume the identity of slot 2.
StoreServ nodes are grouped in pairs, it’s important to pay particular attention to this when zoning host initiators (server HBA ports) to the StoreServ Target ports.
StoreServ7000-HostPorts
Recommendations
  • Each HP 3PAR StoreServ node should be connected to two fabric switches.
  • Ports of the same pair of nodes with the same ID (value) should be connected to the same fabric.
  • General rule – odd ports should be connect to fabric 1 and even ports should be connected to fabric 2.
Figure 1a below identifies physical cabling techniques, mitigating against single points of failure using a minimum of two fabric switches, which are separated from each other.
The example below illustrates StoreServ nodes with supplementary quad port HBA’s:
figure 1a_StoreServ_nPcabling
Moving on to Port Persistence
As already covered by Craig in this blog post, a host port would be connected and zoned on the fabric switch via one initiator (host HBA port) to one HP 3PAR StoreServ target port (one-to-one zoning). The pre-designated HP 3PAR StoreServ backup port must be connected to the same fabric as its partner node port.
It is best practice that a given host port sees a single I/O path to HP 3PAR StoreServ. As an option, a backup port can be zoned to the same host port as the primary port, which would result in the host port seeing two I/O paths to the HP 3PAR StoreServ system. This would also result in the configuration where a HP 3PAR StoreServ port can serve as the primary port for a given host port(s) and backup port for host port(s) connected to its partner node port.
Persistent ports leverage SAN fabric NPIV functionality (N_Port ID Virtualization) for transparent migration of a host’s connection, to a predefined partner port on the HP 3PAR StoreServ array during software upgrades or node failure.
One of the ways this is accomplished is by having a predefined host facing port on the 3PAR StoreServ array, so that in the event of upgrade (node shutdown) or node down status the partner port will assume the identity of its partner port. The whole process is transparent to the host. When the node returns to normal I/O is failed back to the original target port.
Although unconfirmed I have heard that in in future releases of Inform OS we will get this level of protection at the port level.
Essentially for this to work Port Persistence requires that corresponding ‘native’ and ‘guest’ StoreServ ports on a node pair, be connected to the same fibre channel fabric.
Requirements for 3PAR Port Persistence:
  • The same host ports on the host facing HBA’s in the nodes in a node pair must be connected to the same fabric switch.
  • The host facing ports must be set to target mode.
  • The host facing ports must be configured for point-to-point connections.
  • The Fibre Channel fabric must support NPIV and have NPIV enabled on the switch ports.
Checking and enabling NPIV
Brocade Fabric OS (ensure you have the appropriate license which enables NPIV)
admin> portcfgshow ‘port#’
If the NPIV capability is enabled, the results of the portcfgshow command will identify this, i.e NPIV capability ON.
If the NPIV capability is not enabled, you can turn it on with the following command:
admin> portCfgNPIVPort ‘port#’ 1   (1 = on, 0 = off)
 Cisco MDS Series Switches
fabSwitch # conf t
fabSwitch(config) # feature npiv (Enables NPIV for all VSANs on the switch)
QLogic SANbox 3800, 5000 and 9000 Switches
Don’t require a license, it’s enabled by default (just ensure you are using firmware version 6.8.0.0.3 or above).
Now let’s cover Switch Zoning (Fibre Channel)
SAN zoning is used to logically group hosts and storage devices together in a physical SAN, so that authorised devices can only communicate with each other if they are in the same SAN zone.
The function of zoning is to:
  • Restrict access so that hosts can only see the data they are authorised to see.
  • Prevent RSCN (Registered State Change Notification) broadcasts.
What are ‘RSCNs’ ? RSCNs are a feature of fabric switches.  It’s a service of the fabric that notifies devices of changes on the state of other attached devices. For example if a device is reset, removed or otherwise undergoes a significant change in status.
These broadcasts are made to all members in the configured SAN zone. As hosts and storage targets can be grouped in a zone its best practice to reduce the impact of these types of broadcasts (Note: an argument against RSCN’s causing issues in zoning tables is that newer HBA’s do a good job limiting the impact of these types of broadcasts).  Nevertheless, I prefer limiting the number of initiators and targets in a fabric zone to a minimum.
Zoning Types
  • Domain, Port zoning uses switch domain id’s and port numbers to define zones.
  • Port World Wide Name or pWWN zoning uses port World Wide Names to define zones. Every port on a HBA has a unique pWWN. (A host HBA comprises of a – nWWN & a pWWN, the nWWN refers to the whole device whereas the pWWN refers to the individual port.
The preferred zoning unit for the 3PAR StoreServ is pWWN. If you are currently using Domain, Port migrating to pWWN is very easy. Simply create new zones based on the pWWN of the host and the pWWN of the storage target, add these new zones to your fabric switches, zoning-out the references to Domain, Port for that respective HBA port. Some fabric vendor’s support mixing both Domain, Port and pWWN in the same zone. I prefer using one or the other explicitly.
The following command outputs the StoreServ ports and partner ports, which can be used to identify the node pWWN’s for zoning.
3PAR01 cli% showport 
HP 3PAR StoreServ supports the following zoning configurations:
  • Single initiator – Single Target per zone (recommended)
  • Single initiator – Multiple Targets per zone
Use Single Initiator – Single Target per zone over Single Initiator Multiple Targets per zone to reduce RSCN’s as previously discussed.
At the time of writing, HP 3PAR OS implementation documentation references Single Initiator Multiple Targets as the recommended zoning type. However, when I queried this I was directed to use Single Initiator – Single Target Zoning.  HP support pointed me in the direction of this document which identifies Single Initiator – Single Target zoning as best practice: http://www8.hp.com/h20195/v2/GetDocument.aspx?docname=4AA4-4545ENW
HP will support Single Initiator – Multiple Target, but you should not have a single host initiator attached to more than two StoreServ target ports!
Host port WWN’s should be zoned in partner pairs. For example if a host is zoned to node port 0:2:1, then it should be zoned to node port 1:2:1 (I’m speculating here, but I guess this is because controller nodes mirror cache I/O, so that in the event of node failure write operations in cache are not lost – hence we zone in node pairs and not across nodes from different pairs).
After you have zoned the host pWWN to the StoreServ node pWWN, you can use the 3PAR CLI showhost command to ensure that each host initiator is zoned to the correct StoreServ target ports (ensuring initiators go to different targets over different fabrics).
Figure 1b represents a staggered approach where you would have odd numbered VMware hosts connecting to nodes 0 & 1, and even numbered hosts connecting to nodes 2 & 3 (Note: currently the StoreServ is designed to tolerate a single node failure only, this includes the 8-node StoreServ 10800 array).
The example depicts Single Initiator – Single Target zoning, so a host with two HBA ports connecting over two fabrics will have a total of four zones (two per fabric). In case you were wondering the maximum allowed is eight (also known as fan-in limitation which is four per fabric).
figure 1b_host_zoning
Here are some additional points to be aware of
 Fan-in/Fan-out ratios:
  • Fan-in refers to a host server port connected to several HP 3PAR storage ports via Fibre Channel switch.
  • Fan-out refers to the HP 3PAR StoreServ storage port that is connected to more than one host HBA port via Fibre Channel switch.
Note: Fan-in over subscription represents the flow of data in terms of client initiator to StoreServ target ports. HP/3PAR documentation states that a maximum of four HP 3PAR storage system ports can fan-in to a single host server port (if you are thinking great, I’ll connect my VMware host to 8 ports [four per fabric] think again.  Using this approach when you have hundreds of hosts can quickly reach the maximum StoreServ port connection limitation which is 64!) it’s just not necessary.
StoreServ Target Port Maximums (As per 3PAR InForm OS 3.1.1 please observe the following):
  • Maximum of 16 hosts initiators per 2Gb HP 3PAR StoreServ Storage Port
  • Maximum of 32 hosts initiators per 4Gb HP 3PAR StoreServ Storage Port
  • Maximum of 32 hosts initiators per 8Gb HP 3PAR StoreServ Storage Port
  • Maximum total of 1,024 host initiators per HP 3PAR StoreServ Storage System
HP documentation states that these recommendations are guidelines, adding more than the recommended hosts should only be attempted, when the total expected workload is calculated and shown not to overrun either the queue depth or throughput of the StoreServ node port.
Note: StoreServ storage ports irrespective of speed, will negotiate at the lowest speed of the supporting fabric switch (keep this in mind when calculating the number of host connections).
The following focuses on changing the target port queue depth on a VMware ESX environment.
The default setting for target port queue depth on the ESX host can be modified to ensure that the total workload of all servers will not overrun the total queue depth of the target HP StoreServ system port. The method endorsed by HP is to limit the queue depth on a per-target basis. This recommendation comes from limiting the number of outstanding commands on a target (HP 3PAR StoreServ system port), per ESX host.
The following values can be set on the HBA running VMware vSphere. These values limit the total number of outstanding commands the operating system routes to one target port:
  • For Emulex HBA target throttle = tgt_queue_depth
  • For Qlogic HBA target throttle = ql2xmaxqdepth
  • For Brocade HBA target throttle = bfa_lun_queue_depth
(Note: for instructions on how to change these values follow VMware KB1267‎, these values are also adjustable on Linux Redhat & Solaris).
The Formula used to calculate these values is as follows:
(3PAR port queue depth [see below]) / (total number of ESX severs attached) = recommended value
The I/O queue depth for each HP 3PAR StoreServ storage system HBA mode is shown below:
Note: The I/O queues are shared among the connected host server HBA ports on a first come first serve basis.
HP 3PAR StoreServ Storage HBA I/O queue depth values
Qlogic 2Gb 497
LSI 2Gb 510
Emulex 4Gb 959
HP 3PAR HBA 4Gb 1638
HP 3PAR HBA 8Gb 3276
Well, hopefully you found the above information useful. Here is a high level summary of what we have discussed:
  • Identify and enable NPIV on your fabric switches (Fibre Channel only feature – NPIV-Port Persistence is not present in iSCSI environments)
  • Use Single Initiator -> Single Target zoning (HP will support Single Initiator – Multiple Target, but you should not have a single host initiator attached to more than two StoreServ target ports).
  • A maximum of four HP 3PAR Storage System ports can fan-in to a single host server port.
  • Zoning should be done using pWWN. You should not use switch port/Domain ID or nWWN.
  • A host (non-hypervisors) should be zoned with a minimum of two ports from the two nodes of the same pair. In addition, the ports from a host zoning should be mirrored across nodes.
  • Hosts need to be zoned to node pairs. For example, zoned to nodes 0 and 1 or to nodes 2 and 3. Hosts should NOT be zoned to non-mirrored nodes such as 0 and 3.
  • When using hypervisors, avoid connecting more than 16 initiators per 4 Gb/s port or more than 32 initiators per 8 Gb/s port.
  • Each HP 3PAR StoreServ system has a maximum number of initiators supported, that depends on the model and configuration.
  • A single HBA zoned with two FC ports will be counted as two initiators. A host with two HBA’s, each zoned with two ports, will count as four initiators.
  • In order to keep the number of initiators below the maximum supported value, use the following recommendations:
    • Hypervisors: four paths maximum.
    • Other hosts (non-hypervisors): two paths to two different nodes of the same port pairs.
  • Hypervisors can be zoned to four different nodes but the hypervisor HBAs must be zoned to the same Host Port on HBAs in the nodes for each Node Pair.
Reference Documents
HP SAN Design Reference Zoning Recommendations
HP 3PAR InForm® OS 3.1.1 Concepts Guide
The HP 3PAR Architecture
HP UX 3PAR Implementation Guide
HP 3PAR Red Hat Enterprise Linux and Oracle Linux Implementation Guide
HP 3PAR VMware ESX Implementation Guide
HP 3PAR StoreServ Storage and VMware vSphere 5 best practices
HP 3PAR Windows Server 2012, Server 2008 Implementation Guide
HP Brocade Secure Zoning Best Practises
HP 3PAR Peer Persistence Whitepaper
An introduction to HP 3PAR StoreServ for the EVA Administrator
Building SANs with Brocade Fabric Switches by Syngress

Monday, January 6, 2014

Handy Tip: How to split large Outlook PST files to make Outlook run faster (for free)


I get a lot of email. My work one is split into a working PST file and an couple of archive PST files. I’ve started to find that the archive files are just far to big. It means that my machine struggles to defragment the archive file, and today I came across a nice Microsoft support tip, that means you can split PST files up into smaller, moremanageable file sizes. If you want to read how to do it, see this Microsoft support article (KB932086). Now I can have Archives by year (e.g. WorkArchive2005, WorkArchive2006, etc). Nice! Once you have migrated all of your email out of the existing PST file, create a new one and set that to be your new default mail file. Outlook does not reduce the size of the existing PST when you move or delete items.

Thursday, December 19, 2013

Fedora 19 upgrade to Fedora 20 with FedUp

Common problem that I have encouter in my usage of Linux in last 15 year was upgrade from one to another version of release. For quite time best solution was been provided by Debian, but for other non-deb distributions was quite interesting to do upgrade. It was paint-full and time consuming process.

But after release of Fedora fedup util, situation is quite better. On the begging I have little sceptic when my friend Primoz have told me that there is easy was to do upgrade on Fedora with only one command. Till then, for me only safe was was to make backup of /home folder and to do complete install from scratch. If worked on any distro that I have worked till now (Fedora, CentOS, Ubuntu, LinuxMint ...).

What is FedUp?

FedUp (FEDora UPgrader) is the name of a new system for upgrading Fedora installs in Fedora 18 and later. It replaces all of the previously recommended upgrade methods (PreUpgrade and DVD) that were been used in previous Fedora releases. Anaconda, the Fedora installer, has no built-in upgrade functionality in Fedora 18 or later. It has been completely delegated to FedUp.
Currently, FedUp is capable of handling upgrades between all still-supported Fedora releases using a network repository or a DVD image as the package source. Upgrades from EOL Fedora releases may work, but are not supported.

Today I have tested this new upgrade tool.

Here are some considerations to be acknowledged, and here are steps to perform upgrade:

0. make backup of /home directory (just to be on the safe side)
1. do full upgrade of Fedora 19 with "yum update" command
2. check if FedUp is version 0.8, as 0.7 makes problems, check this link for more info: https://fedoraproject.org/wiki/Common_F20_bugs
3. check FedUp page for complete procedure (here is only short version): https://fedoraproject.org/wiki/FedUp
4. execute command "fedup --network 20" (keep in mind that this is network based upgrade, for ISO based upgrade, check fedup page).

What it download cca 1500 packages (this includes also some aditional repos like RPMFusion, Virtualbox ... etc). It needs about 20 min on HP Folio 9740m i5 1.8 with 4GB ram and 320GB HDD.


5. Reboot PC, and whait for that process to be finished, cca 30 min.
6. You have new Fedora 20 on system :) Enjoy :)


Tuesday, November 26, 2013

[Linux, OpenSSL, expect] Doing SFTP file transfers from a shell script

[Linux, OpenSSL, expect] Doing SFTP file transfers from a shell script


PRODUCT:   OpenSSH_5.4p1, OpenSSL 1.0.0a-fips 1 Jun 2010 
           expect version 5.43.0


OP/SYS:    Linux Fedora 13


COMPONENT:  SFTP, SCP 


SOURCE:     Philippe Vouters
            Fontainebleau/France


LOW-COST HIGH-TECH:  http://techno-star.fr


SYMPTOM(S) or PROBLEM(S):

The SFTP -b or the SCP -B options enables batch mode. However, under OpenSSH
version 5.4p1, these options require an empty passphrase and do not allow for
password prompting. What to do when the remote system only has port 22 opened
and only accepts OpenSSH logging using a login/password pair ? This is where
expect enables to workaround this OpenSSH restriction where you do not have the
target account RSA key with an empty passphrase. If you own the target account
RSA key with an empty passphrase then you may use the simpler

        sftp -b script user@host

or scp equivalent shell command.


SOLUTION or RESPONSE:

Use expect to synchronize with each SFTP/SCP output and to simulate their
inputs. Expect acts on terminal screens much the same way as the non-interactive
telnet tool found elsewhere in this knowledge database.


WORKAROUND or ALTERNATIVE:

In your shell script, use SFTP/SCP in interactive mode and synchronize their
output and input using expect commands.


EXPECT INFORMATION:

expect is an optional software. Under Fedora 13 and a root account, use yum to
install expect.

        # yum install expect


KSH SHELL SCRIPT NOTES:

This ksh script expects that the SFTP software is BSD based and accepts the
[-P port] option. Such an SFTP client is available under Linux Fedora 13. 
Carefully check your "man 1 sftp" before blindly using this ksh script. For 
example this sftp man at http://linux.die.net/man/1/sftp which claims BSD
compatibility is not suited for the below ksh script. The following man at
http://linuxreviews.org/man/sftp/ is fully suited and corresponds to the
author's Linux Fedora 13 computer sftp man which he based this ksh script upon.

If running a Linux SFTP client software whose man is identical to what is
described at http://linux.die.net/man/1/sftp, you would modify all occurences
of -P ${port} in the ksh script below to -oPort=${port} such as given as an
example in the http://linux.die.net/man/1/sftp Web browser displayable man.


KSH SHELL FULL SCRIPT:

#!/bin/ksh
#
#        Copyright (C) 2010 by Philippe.Vouters@laposte.net
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by the
#    Free Software Foundation, either version 3 of the License, or
#    any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>;.
#
# Software Description:
# This software transfers the latest 3PAR (a SAN equipment) weekly*.tbz2 and
# optionally the InSplore*.tbz2 files to /tmp local directory. The InSplore
# file is transfered provided it has been produced the same day than the run of 
# this script.
#
# This script makes uses of optional expect freeware and an smtp client whose
# source code is downloadable from http://vouters.dyndns.org/zip/.
# Under Fedora 12 and a root account:
#     # yum install expect
# For smtp:
#     # unzip -aa smtp.zip
#     # export bin=/usr/local/bin
#     # cd smtp
#     # make -f Makefile_smtp
#
# Enter the IP address or the DNS name with the IP port separated with a colon
# of each Service Processor while incrementing the index.
#
SP_hostname[0]="127.0.0.1:10001" # corresponds to 10.10.31.41:22
SP_hostname[1]="127.0.0.1:10002" # corresponds to 10.10.52.25:22
#
# Indicate your email account characteristics as well as a list of remote 
# recipients with a space as the delimiter in the smtp_destinees variable.
#
smtp_server="smtp.sfr.fr"
smtp_login="Philippe.Vouters@laposte.net"
smtp_password="password"
smtp_destinees="Philippe.Vouters@laposte.fr"

# These are the 3PAR Service Processor (SP) Username and Password. They ought
# to be constant whichever the 3PAR SP.
SP_username="spvar"
SP_password="3parvar"

#
# This function prepares a notification of file transfers from the SP.
#
function send_mail_notification
{
       if [[ $1 != "" && $2 != "" ]]; then
           echo "$1 and $2 available in directory /tmp" >> /tmp/smtp_body.txt
       fi
       if [[ $1 != "" && $2 == "" ]]; then
           echo "$1 available in directory /tmp" >> /tmp/smtp_body.txt
       fi
       if [[ $1 == "" && $2 != "" ]]; then
           echo "$2 available in directory /tmp" >> /tmp/smtp_body.txt
       fi
}

#
# Function get_last_weekly
#
# This function is in charge of copying the last dated weekly report to /tmp
# The last dated weekly report has been produced on the preceeding Sunday.
# Input :
#      - Index toward the DNS or IP address stored into SP_hostname
# Output:
#      - /tmp/
#
function get_last_weekly
{
# Step 1:
# get SP's all files in weekly/ directory using sftp and 
# maintenance SSH account.
#
port=`echo ${SP_hostname[$1]} | sed 's/\([\/A-Za-z0-9\.]*\):\([0-9]*\)/\2/g'`
hostname=`echo ${SP_hostname[$1]} | sed 's/\([\/A-Za-z0-9\.]*\):\([0-9]*\)/\1/g'`
echo "spawn sftp -P ${port} ${SP_username}@${hostname}" > /tmp/except
echo "expect -nobrace \" password: \"" >> /tmp/except
echo "send \"${SP_password}\n\"" >> /tmp/except
echo "expect -nobrace \"\nsftp> \"" >> /tmp/except
echo "send \"ls weekly/\n\"" >> /tmp/except
echo "expect -nobrace \"\nsftp> \"" >> /tmp/except
echo "send \"bye\n\"" >> /tmp/except
echo "wait" >> /tmp/except
echo "exit" >> /tmp/except
Weekly_files=`expect /tmp/except | gawk '{if (/weekly\//) {print $0;}}' | sed 's/\r//g' | sed 's/weekly\///g'`
for Weekly in ${Weekly_files}; do
     lastSunday=`date --date="last Sunday" +%y%m%d`
     echo ${Weekly} | sed 's/${lastSunday}//' > /dev/null
     if [[ $? == 0 ]]; then
         Weekly_file=${Weekly}
     fi
done
# Step 2:
# get SP's last dated weekly*.tbz2 in weekly/ directory using sftp and 
# maintenance SSH account.
echo "spawn sftp -P ${port} ${SP_username}@${hostname}" > /tmp/except
echo "expect -nobrace \" password: \"" >> /tmp/except
echo "send \"${SP_password}\n\"" >> /tmp/except
echo "expect -nobrace \"\nsftp> \"" >> /tmp/except
echo "send \"cd weekly\n\"" >> /tmp/except
echo "expect \"\nsftp> \"" >> /tmp/except
echo "send \"lcd /tmp\n\"" >> /tmp/except
echo "expect -nobrace \"sftp> \"" >> /tmp/except
echo "send \"get ${Weekly}\n\"" >> /tmp/except
echo "expect -nobrace \"\nsftp> \"" >> /tmp/except
echo "send \"bye\n\"" >> /tmp/except
echo "wait" >> /tmp/except
echo "exit" >> /tmp/except
expect /tmp/except
Weekly_file=/tmp/${Weekly_file}
rm -f /tmp/except
}
#
# Function get_last_InSplore
# This function downloads to /tmp the today's Insplore file.
#
# Input :
#    - full path of SP's Insplore file
#    - Index toward the SP's IP address or DNS name.
# Output :
#    - the Insplore filename prefixed with /tmp/
#
function get_last_InSplore
{
# Step 1:
# check SP for today's InSplore file using sftp and 
# maintenance SSH account.
#
port=`echo ${SP_hostname[$2]} | sed 's/\([\/A-Za-z0-9\.]*\):\([0-9]*\)/\2/g'`
hostname=`echo ${SP_hostname[$2]} | sed 's/\([\/A-Za-z0-9\.]*\):\([0-9]*\)/\1/g'`
echo "spawn sftp -P ${port} ${SP_username}@${hostname}" > /tmp/except
echo "expect -nobrace \" password: \"" >> /tmp/except
echo "send \"${SP_password}\n\"" >> /tmp/except
echo "expect -nobrace \"\nsftp> \"" >> /tmp/except
echo "send \"ls $1\n\"" >> /tmp/except
echo "expect -nobrace \"\nsftp> \"" >> /tmp/except
echo "send \"bye\n\"" >> /tmp/except
echo "wait" >> /tmp/except
echo "exit" >> /tmp/except
InSplore_file=`expect /tmp/except | gawk '{if (/$$1/) {print $0;}}'`
#
# Step 2:
# get SP's today's InSplore file if it exists and using the 
# maintenance SSH account.
#
echo ${InSplore_file} | sed 's/not found//'
if [[ $? != 0 ]]; then
   echo "spawn sftp -P ${port} ${SP_username}@${hostname}" > /tmp/except
   echo "expect -nobrace \" password: \"" >> /tmp/except
   echo "send \"${SP_password}\n\"" >> /tmp/except
   echo "expect -nobrace \"sftp> \"" >> /tmp/except
   echo "send \"lcd /tmp\n\"" >> /tmp/except
   echo "expect -nobrace \"sftp> \"" >> /tmp/except
   echo "send \"get $1\n\"" >> /tmp/except
   echo "expect -nobrace \"sftp> \"" >> /tmp/except
   echo "send \"bye\n\"" >> /tmp/except
   echo "wait" >> /tmp/except
   echo "exit" >> /tmp/except
   expect /tmp/except
   InSploreFile=/tmp/$(basename ${InSploreFile})
else
   InSploreFile=""
fi
rm -f /tmp/except
}
#
# Start of main script body.
#
touch /tmp/smtp_body.txt
i=0
until [ $i == ${#SP_hostname[@]} ]; do
  if [[ $SP_hostname[$i] != "" ]]; then
      #
      # First step : get last weekly
      #
      get_last_weekly $i
      #
      # Second step: Isolate the SP identification number from the weekly file.
      #
      LastSunday=`date --date="last Sunday" +%y%m%d`
      Today=`date +%Y%m%d`
      SP_num=`echo ${Weekly_file} | sed 's/\([\/A-Za-z0-9]*\)_weekly_\([0-9]*\)_'"${LastSunday}"'\.tbz2/\2/g'`
      InSploreFile=${SP_num}/insplore/InSplore.*-${SP_num}.${Today}.*.tbz2
      #
      # Third step: download if any today's InSplore file
      #
      get_last_InSplore ${InSploreFile} $i
      #
      # Fourth step: prepare notification email
      #
      if [[ ${InSploreFile} != "" ]]; then
            InSploreFile=$(basename ${InSploreFile})
      fi
      #
      # Prepare mail notification
      #
      send_mail_notification ${InSploreFile} $(basename ${Weekly_file})
  fi
  let i+=1
done
#
# send mail to recipients
#
smtp -o ${smtp_login} -server ${smtp_server} -s "Weekly and Insplore transfers over" -f /tmp/smtp_body.txt ${smtp_destinees}
# do cleanup
rm -f /tmp/smtp_body.txt
exit 0


MORE ABOUT EXPECT:

expect has been written in some compiled code (very likely C language according 
to ldd command below) to produce an executable which is linked with the Tcl
binary library. Here is the proof on Linux Fedora 13 (i686 version):

[philippe@victor ~]$ file /usr/bin/expect
/usr/bin/expect: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

So from above a 32 bits executable

[philippe@victor ~]$ ldd /usr/bin/expect
        linux-gate.so.1 =>  (0x00737000)
        libexpect5.43.so => /usr/lib/libexpect5.43.so (0x00a03000)
        libtcl8.5.so => /usr/lib/libtcl8.5.so (0x00110000)
        libdl.so.2 => /lib/libdl.so.2 (0x009fc000)
        libm.so.6 => /lib/libm.so.6 (0x009d0000)
        libutil.so.1 => /lib/libutil.so.1 (0x06547000)
        libc.so.6 => /lib/libc.so.6 (0x00858000)
        /lib/ld-linux.so.2 (0x00836000)

So from above linked with libtcl library.


HP-UX and EXPECT:

For HP-UX, you may download expect from :
http://hpux.connect.org.uk/hppd/hpux/Tcl/expect-5.45/


REFERENCE(S):

As SFTP -b option does not prompt for any passphrase/password, this solution
is unuseable. The ksh script excerp above is based on one guest input at:
http://www.linux-bsd-central.com/index.php/content/view/26/

Thursday, October 24, 2013

3PAR System Reporter, Part 2

We left off with a Linux host that had been built and configured to begin the installation of 3PAR System Reporter. Let’s continue on and get System Reporter installed and configured.
As a recap from Part 1, we are building a System Reporter system in Linux. I have chosen to use RedHat Enterprise Linux 5.8, along with MySQL for the database backend. Both System Reporter and MySQL will be hosted on the same server.
So let’s recap some file locations first, as we will need them later on.
The 3PAR CLI was installed into /opt/3PAR/inform_cli_3.1.1. You should have 2 files copied from the System Reporter CD, onto your system. They are sampleloop-.i386.rpm and sysrptwebsrv-.i386.rpm. At the time of writing, the current versions were 2.9-2 for sampleloop and 2.9-2 for sysrptwebsrv, but make sure to check with your 3PAR representative for the most recent versions.
We begin by making some modifications to the MySQL installation.
  1. Open /etc/my.cnf with your editor of choice (mine is vi )
    1. Comment out the socket= line, and add the line below underneath:
      1. socket=/var/run/mysqld/mysqld.sock
    1. Above [mysqld_safe], add the following line:
      1. max_allowed_packet=32M
    2. Save the file, and then restart mysql
      1. /etc/init.d/mysqld stop
      2. /etc/init.d/mysqld start
  2. Check to make sure the new socket file exists
    1. ls –al /var/run/mysqld/mysqld.sock
Now we are going to create the System Reporter database and users, and then grant those users access to the database.
  1. Connect to your MySQL database
    1. mysql –u root –p
      • when prompted, enter the password you defined for the root user
    1. Create the inservstats database:
      • create database inservstats;
    2. Create the cliuser and webuser users
      • create user cliuser identified by ‘3psrcli’;
      • create user webuser identified by ‘3parweb’;
    3. Grant privileges to the System Reporter users, by issuing the below commands:
      • use inservstats
      • grant all on * to cliuser;
      • grant select on * to webuser;
    4. Quit out of the database:
      • exit

Installing the SampleLoop applications

With the database and users created, we are able to start installing the software. Before we start, make sure to check to ensure the 32 bit package of GD is installed, by issuing
yum –y install gd.i386
. You should get a prompt back saying it’s installed and the latest version, otherwise it will install the missing package(s).

  1. Install the sampleloop package, which you copied from the System Reporter CD earlier
    • rpm –ivh sampleloop-.i386.rpm
      (substiture ver with your version)
  2. Edit the /etc/sampleloop.confconfiguration file, by opening it with your favorite editor. You will need to perform the following edits:
    • Change the line “set Sysdb::cli” to match your installed CLI location, mine was /opt/3PAR/inform_cli_3.1.1/bin/cli
    • Change the line “set Sysdb::smtpserver” to your local mail server address
    • Change the line “set Sysdb:smtporig” to the FROM email address System Reporter should use when sending you emails.
    • Change the “set Sysdb::smtpuser” and “set Sysdb:smtppasswd” to their respective user and password values, if your mail server requires you to login to send mail. If these are not needed, simply comment them out by putting a # in front of the lines.
    • Change the line “set Sysdb::dbhost” to the IP address of your MySQL server
    • Change the line “set Sysdb::dbname” to the database name you created above. In my example, we used “inservstats”
  3. Now we will need to create the password file used by the sampleloop mechanism to access the CLI. Open/Create the file “/etc/sampleloop_dbpwfile”
    • On the first line, enter the username and password for the cli user, separated by a single space.
      • ie. “cliuser 3psrcli”
    • Save the file, and exit out of the editor.
  4. You are now ready to startup the SampleLoop processes.
    • run the below script:
      1. /etc/init.d/sampleloop startup
    • If this fails to start, check the log located in /var/log/sampleloop/sampleloop.log for hints on what went wrong. It’s usually a password mistyped.
  5. If everything starts successfully, add sampleloop to the default startup runlevels
    • chkconfig --add sampleloop

Installing the System Reporter Webserver Files

Now we have the database and users created, sampleloop applications installed, and SampleLoop up and running. The next step is to install the sysrptwebsrv RPM package. This package is found on the System Reporter CD, and should be copied on to your Linux system.
  1. To install the packages, run the below:
    • rpm -ivh sysrptwebsrv-2.9-2.i386.rpm
    • Ensure it was installed successfully.
  2. We now need to setup two config.tcl files for the webserver.
    1. The first is at /var/www/cgi-bin/3par-rpts/config.tcl. Open this file in your favorite editor, and make the below changes:
      • Change the line “set Sysdb::cli” to match your installed CLI location, mine was /opt/3PAR/inform_cli_3.1.1/bin/cli
      • Change the line “set Sysdb::dbhost” to the IP address of your MySQL server
      • Change the line “set Sysdb::dbname” to the database name you created above. In my example, we used “inservstats”
      • Change the line “set Sysdb::dbuser” to webuser
      • Change the line “set Sysdb::dbpasswd” to the password you set for webuser, in my example it was 3parweb.
      • Change the line “set Sysdb::smtpserver” to your local mail server address
      • Change the line “set Sysdb:smtporig” to the FROM email address System Reporter should use when sending you emails.
      • Change the “set Sysdb::smtpuser” and “set Sysdb:smtppasswd” to their respective user and password values, if your mail server requires you to login to send mail. If these are not needed, simply comment them out by putting a # in front of the lines.
    2. The second file is located at /var/www/cgi-bin/3par-policy/config.tcl. Open this file in your favorite editor, and make the below changes:
      • Change the line “set Sysdb::cli” to match your installed CLI location, mine was /opt/3PAR/inform_cli_3.1.1/bin/cli
      • Change the line “set Sysdb::dbhost” to the IP address of your MySQL server
      • Change the line “set Sysdb::dbname” to the database name you created above. In my example, we used “inservstats”
      • Change the line “set Sysdb::dbuser” to cliuser
      • Change the line “set Sysdb::dbpasswd” to the password you set for cliuser, in my example it was 3psrcli.

Test your System Reporter setup

You should now have a working System Reporter configuration. You can access System Reporter by going to:
http:///3par/
Part 3 of my System Reporter series will involve adding the Inserv system to System Reporter, as well as setting some basic options up, and going over the various tabs available to you.

3PAR System Reporter, Part 1

System Reporter is a 3PAR tool that provides informative reporting about your 3PAR arrays, as well as being able to build custom reports, and schedule daily execution and email of any report.
System Reporter is also required to be installed, in order to use Adaptive Optimization, as System Reporter is used to determine which chunklets are to be migrated between which CPG’s. All the Adaptive Optimization configuration is done from within System Reporter’s web interface.
System Reporter can be installed on Windows 2003, Windows 2008, or RedHat Enterprise Linux 5. It may use either Microsoft SQL, MySQL, Oracle, or SQLite as it’s backend database, although there are restrictions on each database. MySQL seems to be the recommended database to use, as it has the fastest query times due to it’s MyISAM structure, and it has minimal restrictions across the server Operating Systems.
I will be installing and configuring System Reporter 2.8 on a RedHat Enterprise Linux 5.8 virtual machine. I will be using MySQL as the database backend, which will be installed on the same host virtual machine. In part 2 of this series, I will be then be installing and configuring System Reporter. Part 3 will be configuring and adding a 3PAR InServ system, in my case a T400. Part 4 will be setting up Adaptive Optimization. Part 5 will be all about reports, and how to create custom and scheduled reports.

System Requirements

System Reporter has the below requirements for it’s host system:
  • CPU: Pentium 4, 3Ghz or faster
  • Memory: 1GB
  • Disk: 20GB free space
Please make sure your host system meets or exceeds these requirements, prior to installation.

Install Linux

The first step, is to make sure you have a freshly installed and updated RedHat EL 5 installation. I chose to use the normal installation, and deselected anything I didn’t want. I left the apache webserver installed, as well as X11, but removed all Window Managers. After fully updating the installation with ‘yum –y update && yum –y upgrade’ I began the rest of my installation.

Install Apache Webserver

From the command line, issue the below command:
yum –y install httpd
This will install the Apache Webserver, if it has not already been installed.

Install 3PAR CLI

The System Reporter installation CD has both a Windows and a Linux directory, which contain all files necessary for installation. In my example, we are using Linux, so to install the CLI, you will need to copy the Linux/CLI/setup.bin file from the CD, on to your Linux host.
Once the file has been copied, change it’s permissions to be executable, and run the file:
 chmod +x setup.bin
./setup.bin
You will be prompted several questions, including where to install the CLI. I would recommend using the /opt/ location it defaults to. Make sure you write down this location, as it will be needed later in the installation. Once the installation is completed, it’s time to move on.

Install MySQL

Next, you need to install mysql. Connect to your linux server with ssh, and issue the command:
yum –y install mysql-server
Once the installation is completed, you will need to set the root database password.
To do this, issue the below commands:
mysqladmin -u root password "NEWPASSWORD"
mysqladmin -u root -h localhost -p password "NEWPASSWORD"

Installing System Reporter

Now that your system is ready, you can move on to Part 2, Installing System Reporter. Part 2 will be posted within a few days.
If you have built your base system as a Virtual Machine, now would be a great time to take a snapshot, or build a template for future installations.

How to use DiskSpd to simulate Veeam Backup & Replication disk actions

This HOW-TO contains information on how to use Microsoft© DiskSpd to simulate Veeam Backup & Replication disk actions to measure disk pe...