Improving SAR of Virtualization Environments

Improving “SAR” of Virtualization
OSs, Networks and Storages
Yousof Mohammed Osama Radi
A thesis submitted for the requirements of the degree of Master of
Science [Computer Science]
Supervised By
Prof. Osama A. Abulnaja
FACULTY OF COMPUTING AND INFORMATION
TECHNOLOGY
KING ABDULAZIZ UNIVERSITY
JEDDAH – SAUDI ARABIA
DHU AL-QA’DAH 1432H – OCTOBER 2011G

By
This thesis has been approved and accepted in partial fulfillment of the
requirements for the degree of Master of Science [Computer Science]
EXAMINATION COMMITTEE
Name Rank Field Signature
Internal Examiner Kamal M. Jambi Prof Computer Science
External Examiner Ahmed A. A. Adas Assoc. Prof. Systems Engineering
Advisor Osama A. Abulnaja Prof Computer Science
KING ABDULAZIZ UNIVERSITY
DHU AL-QA’DAH 1432H – OCTOBER 2011G

DEDICATION
I dedicate this thesis to my loved parents and wife for their love
support, patience and encouragement.

ACKNOWLEDGEMENT
I would like to express my gratitude to my supervisor, Prof. Osama A.
Abulnaja. Since the beginning he has kindly spent his time discussing
with me the problems of my research. He has been very supportive of
the subject I was research in. His advice and his comments on my thesis
have been valuable.

vi
ABSTRACT
In this work we study operating system virtualization which allows us run
multiple operating systems and user applications on the same hardware
simultaneously, where the operating systems are completely isolated from each other
logically.
If a physical server use a virtualization technology and number of virtual servers are
hosted and running on that single physical server, this will increase the information
technology data center workload management and responsibility, because an outage
of this virtualized sever will cause an outage for all hosted virtual servers. To prevent
such situations which it is critical in a virtualized environment, We study how to
increase the SAR (Scalability, Availability And Reliability) of the virtualized
environment in different levels, starting from files of Operating System level to
network, storage design and resources control (memory’s and CPUs). We studied
Solaris virtualization technology (Solaris Container), because it is one of the best
virtualization technologies. The Solaris operating system and the Solaris virtual
environment are not fault tolerant by default. In this study we will build SAR main

vii
operating system and its virtual environments (Solaris Containers), by design and
implement internal packages in Solaris for network (like IPMP or Aggregation),
Storage (like SVM or ZFS), and by optimizing the shared resources (memory’s and
CPUs) among the main and its virtual operating systems.

viii
TABLE OF CONTENTS
EXAMINATION COMMITTEE
DEDICATION
ACKNOWLEDGEMENT......................................................................................v
ABSTRACT ...........................................................................................................vi
TABLE OF CONTENTS.................................................................................... viii
LIST OF FIGURES ...............................................................................................xi
LIST OF TABLES ...............................................................................................xiv
LIST OF SYMBOLS AND TERMINOLOGY....................................................xv
CHAPTER I: INTRODUCTION...........................................................................3
1.1 Failure Characteristic ........................................................................................3
1.2 Scalability, Availability and Reliability (SAR).......................................................7
CHAPTER II: VIRTULIZATION.......................................................................11
2.1 History............................................................................................................11
2.2 Introduction....................................................................................................13
2.3 Why Virtualization?.........................................................................................15
2.4 Virtualization Survey.......................................................................................21
2.5 Virtualization Definition ..................................................................................24
2.6 Virtualization Types.........................................................................................24
2.6.1 Hardware-Virtualization..............................................................................25
2.6.2 Para –Virtualization (Hypervisor).................................................................26
2.6.3 Operating System –Virtualization................................................................27
2.7 Virtualization VS Cloud Computing..................................................................28
CHAPTER III: LITERATURE REVIEW ..........................................................30
3.1 High Availability Using Virtualization...............................................................30
3.2 Application Recovery On Various Network Architecture Employing Solaris
Operating System Metadata And Virtualization. .........................................................32
CHAPTER IV: RESEARCH DESIGN AND METHODOLOGY......................33
4.1 VMware..........................................................................................................34
4.2 Solaris (OS) .....................................................................................................34
4.3 Network..........................................................................................................35

ix
4.4 File System......................................................................................................37
4.5 Virtual OS (Zone), Network And File System....................................................38
CHAPTER V: DESIGN AND CONFIGURE SAR NETWORK........................39
5.1 IPMP (Internet Protocol Multipathing) ............................................................39
5.2 Aggregation ....................................................................................................46
5.3 IPMP And Aggregation ....................................................................................52
CHAPTER VI: DESIGN, CONFIGURE AND IMPLEMENT SOLARIS
VOLUME MANAGER (SVM).............................................................................53
6.1 SVM Requirement...........................................................................................53
6.2 SVM Implementation......................................................................................55
CHAPTER VII: DESIGN, CONFIGURE AND IMPLEMENT ZFS.................63
7.1 Why ZFS?........................................................................................................63
7.2 ZFS Architecture..............................................................................................64
7.3 ZFS HA Design.................................................................................................67
CHAPTER VIII: DESIGN, CONFIGURE AND INSTALLATION ORACLE
SOLARIS VIRTUALIZATION ...........................................................................69
8.1 Oracle Solaris Virtualization Type....................................................................70
8.2 Why Zone?......................................................................................................72
8.3 Zone Feature...................................................................................................72
8.4 Zone High Availability Network .......................................................................74
8.5 Zone High Availability Storage.........................................................................74
8.6 Zone Design....................................................................................................75
8.7 Zone States Model ..........................................................................................76
8.8 Zone Creation .................................................................................................78
8.9 Zone Cloning...................................................................................................83
CHAPTER IX: DESIGN, CONFIGURE AND IMPLEMENT SOLARIS LIVE
UPGRADE ............................................................................................................86
9.1 Live Upgrade And SVM....................................................................................89
CHAPTER X: RESULT AND ANALYSIS .........................................................92
10.1 Unplanned Outage – Storage ..........................................................................92
10.2 Unplanned Outage – Network.........................................................................95
10.3 Planned Outage – Storage...............................................................................96
10.4 Planned Outage – Operating System...............................................................98
CHAPTER XI: CONCLUSIONS AND RECOMMENDATIONS ...................100
11.1 Conclusions...................................................................................................100
11.2 Recommendations........................................................................................101

x
LIST OF REFERENCES ...................................................................................103

xi
LIST OF FIGURES
Figures Page
1.1 Hardware Failures During A Products Life ....................................................4
2.‫‏‬1 Catalog And Instances Of Os Virtualization Technologies ...........................12
‫‏‬2.2 Single Applications On Single Server.............................................................13
‫‏‬2.3 Host-Per-Host Redundancy............................................................................14
‫‏‬2.4 ITDC Landscape .............................................................................................15
‫‏‬2.5 Server Load Capacities...................................................................................16
‫‏‬2.6 Servers Consolidation .....................................................................................16
‫‏‬2.7 Virtualization Solutions ..................................................................................17
‫‏‬2.8 CAPEX And OPEX.........................................................................................19
‫‏‬2.9 How Important Were Each Of The Following Goals At The Time You
Originally Decided To Implement Server Virtualization? ..........................22
‫‏‬2.10 Which Of These Goals Were Actually Achieved From Deploying Server
Virtualization?...............................................................................................23
‫‏‬2.11 Traditional Server Vs Virtualized Server ....................................................24
‫‏‬2.12 Hardware-Virtualization One Domain.........................................................25
‫‏‬2.13 Hardware-Virtualization Multiple Domains................................................26
‫‏‬2.14 Hypervisor Virtualization.............................................................................27
‫‏‬2.15 Operating System –Virtualization................................................................28

xii
‫‏‬4.1 Methodology....................................................................................................33
‫‏‬5.1 IPMP & High Available Network Topology ..................................................40
‫‏‬5.2 Probe Based Ip Multipathing .........................................................................41
‫‏‬5.3 Link Aggregation Topology............................................................................48
‫‏‬6.1 Available Disk .................................................................................................54
‫‏‬6.2 UFS Disk Partitions.........................................................................................54
‫‏‬6.3 Meta Data Base Status ....................................................................................56
‫‏‬6.4 SVM Design.....................................................................................................56
‫‏‬6.5 SVM Root Mirror 1'st Side.............................................................................58
‫‏‬6.6 Metadevice Design...........................................................................................58
‫‏‬6.7 Metaroot d0 And System File .........................................................................59
‫‏‬6.8 Os With SVM ..................................................................................................59
‫‏‬6.9 Metastat Before Attach The Mirror...............................................................60
‫‏‬6.10 Metastat After Attach The Mirror ...............................................................61
‫‏‬6.11 Root Metadevice Mirror ...............................................................................62
‫‏‬7.1 ZFS Pool ..........................................................................................................65
‫‏‬7.2 Zpool List ........................................................................................................66
‫‏‬7.3 Zpool Status.....................................................................................................66
‫‏‬7.4 ZFS Mirror “Raid1” .......................................................................................67
‫‏‬7.5 Raid1 Zpool Status..........................................................................................68
‫‏‬8.1 Oracle Solaris Virtualization ..........................................................................70
‫‏‬8.2 Zone Architecture ...........................................................................................71
‫‏‬8.3 Zone Inherited Directories..............................................................................76
‫‏‬8.4 Zone States Model...........................................................................................77
‫‏‬8.5 New Zone.........................................................................................................80

xiii
9.1 Live Upgrade With SVM ................................................................................87
9.‫‏‬2 Alternative Boot Environment SVM Design..................................................89
‫‏‬10.1 HA Storage Design ........................................................................................93
‫‏‬10.2 Standard Backup And Restore Design.........................................................93

xiv
LIST OF TABLES
Table Page
Table 1.1 Hardware Failures Causes 4
Table 1.2 Availability Percentages And Yearly Downtime 9
Table 5.1 Aggregation Vs IPMP 52
Table 7‫‏‬VII.1 UFS, SVM And ZFS Source Code Size 64
Table 9.1 Solaris Live Upgrade (Command Reference) 88
Table 10.1 Unplanned Storage Outage Activity 94
Table 10.2 Network Unplanned Outage With And Without SAR
Design
95
Table 10.3 Planned Backup Storage Activity 96
Table 10.4 Planned Replace Storage Activity 97
Table 10.5 Maintenance In Non-Virtualized And In Virtualized
Environments
98
Table 10.6 Virtualization Agility 99

xv
LIST OF SYMBOLS AND TERMINOLOGY
IP Internet Protocol.
TCP Transmission Control Protocol.
IT Information Technology.
ITDC Information Technology Data Center
SLA Service Level Of Agreements.
SAR Scalability, Availability And Reliability.
MTBF Mean Time Between Failure.
MTTR Mean Time To Repair.
CAPIX Capital Expense.
OPEX Operation Expense.
HA High Availability.
DEV development.
QA Quality Insurance.
PROD Production.
LDOM Logical Domain.
ZONE Solaris Operating System Virtualization.
Global Domain Main Operating System.
Local Domain Virtual Operating System.
NAS Network Attached Storage
SAN Storage Attach Network

2
NIC Network Card.
IPMP IP Multipathing
Aggregation Solaris High Available Network Technology
SVM Solaris Volume Manager
ZFS ZITA file system.
ZFS Pool Merges The Storage Together To Be One Pool Of Storage
Resource.
Live Upgrade ORACLE Solaris package.

3
ICHAPTER
INTRODUCTION
The primary objective of information technology data center (ITDC) is to
build systems that satisfy user service level agreement (SLA) with measurable
improvements to mission capability and operational support in a timely manner, and
at a fair and reasonable price.
My thesis supports that objective. It addresses scalability, availability, and reliability
(SAR) as essential elements of information technology data center (ITDC)
virtualization capability.
In this thesis I will explain how scalability, reliability and availability (SAR) are key
components to planning and implementing a highly available virtual operating
system, I will focuses on what can be done to achieve satisfactory levels of SAR and
how to assess SAR.
1.1 Failure Characteristic
1.1.1 Hardware Failures
Hardware failures are typically characterized by a bathtub curve. An example curve
is shown in Figure 1.1. The chance of a hardware failure is high during the initial life

4
of the module. The failure rate during the rated useful life of the product is fairly
low. Once the end of the life is reached, failure rate of modules increases again.
Figure 1.1 Hardware Failures During A Products Life
Normally in Information Technology Data Center (ITDC) we may face failure during
useful life, or End of life in carless ITDC.
The Hardware failures during a products life can be attributed to the following
causes:
Table 1.1 Hardware Failures Causes
FAILURE DESCRIPTION
Design failures This class of failures takes place due to inherent design flaws in
the system. In a well-designed system this class of failures
should make a very small contribution to the total number of
failures.
Infant Mortality This class of failures cause newly manufactured hardware to
fail. This type of failures can be attributed to manufacturing

5
FAILURE DESCRIPTION
problems like poor soldering, leaking capacitor etc. These
failures should not be present in systems leaving the factory as
these faults will show up in factory system burn in tests.
Random Failures Random failures can occur during the entire life of a hardware
module. These failures can lead to system failures. Redundancy
is provided to recover from this class of failures.
Wear Out Once a hardware module has reached the end of its useful life,
degradation of component characteristics will cause hardware
modules to fail. This type of faults can be weeded out by
preventive maintenance and routing of hardware.
1.1.2 Software Failures
Software failures can be characterized by keeping track of software defect density in
the system. This number can be obtained by keeping track of historical software
defect history.
Defect density will depend on the following factors:
 Software process used to develop the design and code (use of peer level
design/code reviews, unit testing).
 Complexity of the software.
 Size of the software.
 Experience of the team developing the software.
 Percentage of code reused from a previous stable project.

6
 Rigor and depth of testing before product is shipped.
 Defect density is typically measured in number of defects per thousand lines of
code (defects/KLOC). [1][2]

7
1.2 Scalability, Availability and Reliability (SAR)
In order to remain competitive organization, the Information Technology Data
Center (ITDC) continually adds new business plan and work, because of that the
ITDC should be Scalable, highly Available and Reliable, To make the ITDC more
efficient flexible and cost-effective.
Let’s go through SAR what it is, why it is important, and how is the information
technology data center (ITDC) without SAR in virtualization solution.
1.2.1 Scalability
Scalability is the measure of how well an Information Technology Data Center
(ITDC) can grow to meet new demands. There are two scalability strategies you can
implement: scaling up or scaling out. Because of virtualization technology we can
increase system resources (such as processors, memory, disks, and network adapters)
to our existing hardware or replacing existing hardware with greater system
resources.
For example, if the current hardware is not providing adequate performance for your
users, you can consider adding RAM or central processing units (CPUs) to the
servers to meet the demand. [2]

8
1.2.2 Availability
In the ITDC, the metric used to measure availability is the percentage of time
that the system is capable of serving its intended function.
The following formula is used to calculate availability levels:
Availability
Percentage
=
Total Elapsed Time - Sum Of Downtime
Total Elapsed Time
Availability is typically measured in "nines." For example, a solution with an
availability level of "three nines" is capable of supporting its intended function 99.9
percent of the time its equivalent to an annual downtime of 8.76 hours per year on a
24x7x365 (24 hours a day/seven days a week/365 days a year) basis.

9
The following table lists common availability levels that many organizations attempt
to achieve.
Table 1.2 Availability Percentages And Yearly Downtime
Availability 24-hour day 8-hour day
90% 876 hours (36.5 days) 291.2 hours (12.13 days)
95% 438 hours (18.25 days) 145.6 hours (6.07 days)
99% 87.6 hours (3.65 days) 29.12 hours (1.21 days)
99.90% 8.76 hours 2.91 hours
99.99% 52.56 minutes 17.47 minutes
99.999% ("five nines") 5.256 minutes 1.747 minutes
100.00% 31.536 seconds 10.483 seconds

10
1.2.3 Reliability
Reliability measures are generally used to calculate the probability of failure
for a single solution component. Two measures used to define a component or
system's reliability:
a. Mean Time Between Failures (MTBF).
MTBF is the average time interval, usually expressed in thousands or tens of
thousands of hours (sometimes called power-on hours or POH), that elapses
before a component fails and requires service. MTBF is calculated by using the
following equation:
Mean Time Between Failures =
Total Elapsed Time - Sum Of
Downtime
number of failures
b. Mean Time To Repair (MTTR).
MTTR is the average time interval (usually expressed in hours) that it takes to
repair a failed component. The reliability of all solution components—for
example, server hardware, operating system, application software, and
networking can affect the availability. [2]

11
IICHAPTER
VIRTULIZATION
2.1 History
Computer was designed originally for s specific task, this idea start to change
since 1950’s when the computer become faster than the human interaction like apply
new jobs ,change the media or error handling, so the human interaction become as an
overhead.
In 1960’s the operating system play the human interaction rolls, manage the
interaction between the system jobs, multi-user OSs were being researched. An OS
developed at Massachusetts Institute of Technology, called the Compatible Time-
Sharing System, (CTSS), was capable of running normal batch jobs, while at the
same time allowing users to interactively access the same computer for execution of
commands in real time.
IBM announced its IBM System/360 that enabled timesharing by allowing more than
one OS to run at the same time, then in 1970’s the study to provide a very high
degree of application isolation, increase flexibility of resource allocation, as well as
to achieve a better hardware utilization was by IBM in 1976 IBM's S/390 (now z/900
Series) and AS/400 products support logical partitioning. Then in the 1990’s the

12
VMware and Microsoft introduce the hypervisor, is a low-level software layer that
allows multiple operating systems to run on a computer at the same time.
By early 2007, a lot of projects have been focusing on virtualizing operating system
environments, such as FreeBSD Jail, Linux-VServer, and Virtuozzo, Solaris zone.[3]
Figure 2.1 Catalog And Instances Of OS Virtualization Technologies
Resources
allocation
Virtualizing OS
Solaris Zones
FreeBSD Jail
Linux‐Vserver
Virtuozzo
Multiple OS
Virtual
machine
IBM S/360 line
VMware
Xen, TRANGO
Logical
partition
IBM z/900
IBM AS/400

13
2.2 Introduction
Virtualization is the trend sweeping enterprise IT, overall environment has
hundred thousands of server been shipped worldwide every year, these getting
deployed by hundreds in the large enterprise in old fashion design, that run single
application on single operating system installed on a single server.
Figure 2.2 Single Applications on Single Server
To make them completely fault-tolerant, it was a highly expensive method (host per
host redundancy) in terms of hardware and, software, footprint and the maintenance
cost. Even if they were not heavily utilized.
SERVER1
• Application
SERVER2
• Application
SERVER3
• Application

14
Figure 2.3 Host-Per-Host Redundancy
The cost it’s not the only problem that the ITDC face usually and its maybe not a
problem for some customer, but the main problem is the time to deploy new business
which it takes months to assemble and install the servers.
The other problem the non-virtualized ITDC facing is the homogeneous environment
which all ITDC and vendor trying to achieve, is the dummy task, because all the
server use the same operating system type and updated with the same level, so if they
want to updated or add security patch they have to repeated on all those servers, by
virtualization we can upgrade not only patch and also without outage to the business
using some advanced virtualization techniques and tools.
The virtualization become the key to the information technology data centers
(ITDC), to achieve new level of challenge by cutting the cost of hard ware and
software using server consolidation and to achieve new level of performance by
sharing the resource of enterprise machine.
Virtualization it’s not new technology but its new trend to increase the SAR
(Scalability, Availability and Reliability) in the ITDC.
Sales Finance HR

15
2.3 Why Virtualization?
Without virtualization the server architecture models and the project design
focused on defining how many servers would be required to implement a new
application land scape in ITDC, from first stage which its development (DEV) to
build and test to the second stage which it’s the quality insurance (QA) to simulate
the production environment, then finally to the production (PROD).
Figure 2.4 ITDC Landscape
Depending on availability and redundancy requirements, the number of users, and
other factors, in each stage of the ITDC landscape multiple servers might be
required, even if they were not heavily utilized.
Virtualized environments are easier than physical environments to manage. These
environments particularly simplify business continuity planning and server
manageability and provide more accurate replication of the operating environment.
2.3.1 Virtualization Benefits
The design, implementation and managing the virtualized environment is
different than the non-virtualized one, in all level from network, storage, racks to
finally the application or end user.
DEV
•Builed
•Test
QA
•Simulate the PROD PROD

16
2.3.2 Server Consolidation
Based on the report of the Microsoft, Intel and other companies “Most the
servers operate at only about 5-15% of their total load capacity”.
Figure 2.5 Server Load Capacities
The focus shift from increasing performance and availability by buying newer and
more powerful server to reducing the cost of IT infrastructure by server
consolidation and increasing utilization of hardware, and better service levels
agreement.[4][5][6]
Figure 2.6 Servers Consolidation
We can accomplish this through N1 Grid computing, a new approach for managing
information technology data centers (ITDC). It will view an (ITDC) as a single pool
of resources delivering services.
0
25
50
75
100
0:00 2:00 4:00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00
USER SYS IDLE

17
Services may be run on any system within the pool that provides the resources
needed to meet the performance. Creating and managing this single pool of resources
requires virtualization.
Figure 2.7 Virtualization Solutions
By Operating System virtualization we can have flexible software-defined
boundaries for isolating software applications and services. These applications can
then be managed independently of each other, even while running with the same
instance of the kernel in base operating system, without the extra overhead of
managing multiple Operating System instances for each application.
2.3.3 Simplifying Operations:
Server virtualization effectively hides hardware details from software,
allowing the hardware to be truly interchangeable without affecting the software.
Financ
e
Sale
s
HR
Financ
e
Sale
s
HR
DB

18
The application installation will not change and the application administrator will not
feel any change when he works on virtualized environment it’s totally isolated and
transparence.
The management will be much easier in term of allocating the resources or moving
the virtual operating system from physical server to another.
2.3.4 Improving Utilization And Uptime
Server virtualization helps ITDC gain optimal use of existing resources. A
single physical server may now host many virtual workloads that previously would
have required many physical servers (Server’s Consolidation). Additionally, because
workloads can be relocated or replicated easily, administrators can move them when
performing maintenance without affecting service levels (SLA).
Virtualization helps improve utilization and uptime by:
 Enabling safe resource sharing on industry-standard servers—if one virtual server
fails, the others aren’t affected.
 Leveraging the ability to migrate workloads dynamically from one physical
server to another. Thus, workload SLAs can automatically match demand with
capacity, and system maintenance may be performed without disrupting business
services.
 Empowering disaster recovery (DR) operations by restoring lost services
regardless of the target physical platforms providing the service. Or even use the
disaster recovery (DR) site as active site also like in some advanced feature of
virtualization technology.

19
2.3.5 Cost Saving
Based on the capacity management of the ITDC we can manage and utilize
benefits brought by server virtualization facilitate cost-saving “pay as you grow”
The ITDC has expanded the scale of systems so that business can be conducted faster
and more efficiently. But as the number of servers increase, it becomes more
important to reduce their operating, administration cost and power consumption.
Figure 2.8 CAPEX and OPEX
 Capital Expense (CAPEX)
Using virtualization benefits like server consolidation, storage virtualization and
network virtualization we can decrease the number of ITDC capitals like servers,
storages and network switches, cards and cables. Also others like OS, and some
application licenses. [7]

20
 Operation Expense (OPEX)
To administrate the virtualized ITDC equipment from storage, network to server
and operating systems you need to invest on your administration staff and
management tools.
2.3.6 Increasing Availability
The high availability solution usually cost the ITDC a huge budget because
you have to have redundancy on all resources, but by virtualization design and the
utilization report from ITDC capacity group, you can have highly available
environment without any additional cost.
2.3.7 Increasing Scalability
The ability to grow is the main requirement of any ITDC any all layer from
network to storage and finally to introduce new application.
Virtualized environment has the ability to add new virtual storage or virtual network
or even more virtual servers, or upgrade the hard ware of the main server which hosts
the virtual environment.
2.3.8 Increasing Agility
Virtualization allows you to pool and share ITDC resources (CPU, Memory,
Network Card and Storage) to improve utilization and enable supply to meet
business demand and sense.

21
We can create new virtual machine for a customer from our ITDC pools (existing
resource) like CPU, memory, network card and storage, without waiting months to
order new servers.
By using virtualization we can reduce costs and increase agility of ITDC.
The ITDC that using virtualization technology they can create template for their
customer so it will be available we customer need it without wasting the time in
installation and configuration so it will be operating system on the shelf.
2.4 Virtualization Survey
By implementing virtualization technologies in the ITDC, the enterprises
hope to realize a long list of potential benefits hoped to achieve.
Symantec commissioned Applied Research to field the 2011 Virtualization and
Evolution to the Cloud Survey by telephone in April of 2011. They contacted 3,700
enterprises of various sizes in 35 different countries:
 Small enterprises (1,000 to 2,499 employees)
 Medium enterprises (2,500 to 4,999 employees)
 Large enterprises (5,000 or more employees)
The survey revealed a gap between these expectations and reality. We asked
respondents what their goals were at the time they implemented server virtualization.
I will explain the report in two parts:

22
a) How important were each of the following goals at the time you originally
decided to implement server virtualization?
Figure 2.9 How Important Were Each Of The Following Goals At The Time
You Originally Decided To Implement Server Virtualization?
Extending the life of older OS or legacy…
Keep up with emerging technology trends
Mitigate common data center issues
Improve time to deploy new servers (virtual…
Improve server speed to better serve our…
Improve our disaster-recovery readiness
Improve our IT department's overall agility
Improve server manageability
Improve server utilization ratios/reduce server…
Improve uptime/availability of our data center
Reduce operating expense
Reduce capital expense
Improve the scalability of our servers
71%
79%
79%
83%
83%
83%
84%
85%
85%
85%
86%
87%
88%

23
b) Which of these goals were actually achieved from deploying server
virtualization?
They also asked those who have implemented it about the benefits that were
actually realized following implementation.
Figure 2.10 Which Of These Goals Were Actually Achieved From Deploying
Server Virtualization?
In terms of server virtualization, this gap was fairly small. The majority of
enterprises had realized improved scalability, reduced capital and operation expense
(capex/opex) and improved uptime. [8]
Extending the life of older OS or legacy…
Keep up with emerging technology trends
Mitigate common data center issues
Improve time to deploy new servers (virtual…
Improve server speed to better serve our…
Improve our disaster-recovery readiness
Improve our IT department's overall agility
Improve server manageability
Improve server utilization ratios/reduce…
Improve uptime/availability of our data center
Reduce operating expense
Reduce capital expense
Improve the scalability of our servers
71%
77%
79%
79%
79%
82%
82%
85%
82%
78%
76%
75%
81%

24
2.5 Virtualization Definition
Virtualization decouples software from hardware and presents a logical view
of physical hardware to software. In other words, a single server can act and behave
as multiple, independent servers.
So we can run multiple operating systems on a single server.
Figure 2.11 Traditional Server Vs Virtualized Server
2.6 Virtualization Types
There are three major types of virtualization architecture, depends on the hard
ware architecture if it’s SPARC or x86, firmware of the hardware is support
virtualization or not, and the project type.
We could consolidate the ITDC development (DEV) and quality insurance (QA)
environment into one high end server as virtualization solution, you can distribute the

25
resource between these two environments (not sharing), and also sharing the resource
inside its guests operating system. [9]
So we can mix different virtualization architectures in the same virtualized server
2.6.1 Hardware-Virtualization
It's physical computer software that controls its resources CPUs, DIMMs, IOs
and Storages to use these resources in one domain or distributed among number of
domains. So each domain has its own operating system.
This has the advantage of requiring no software layer, no performance impact, and
hardware fault isolation.
This type of virtualization support by SUN Domain in M8000 enterprise server and
IBM Logical partition.
Figure 2.12 Hardware-Virtualization One Domain
Domain 0
CMU 0
• CPU
• DIMM
• IO
CMU 1
• CPU
• DIMM
• IO
CMU 2
• CPU
• DIMM
• IO
CMU 3
• CPU
• DIMM
• IO

26
Figure 2.13 Hardware-Virtualization Multiple Domains
As we see in the [figure 2.13] it is an example about what you can do with SUN
Enterprise SPARC M8000 server. I could have split the CMU's and IOU's up into 4
parts and create up to 16 of the domains.
This splitting of the resource is against the one main goals of the virtualization it’s
the resource sharing.
2.6.2 Para –Virtualization (Hypervisor)
Virtual operating system layer allows multiple operating systems to run on
hardware at the same time as logical domain (LDOM), by virtualizing the CPU and
Memory and network, and distributed or sharing it among the LDOMs, each
LDOM’s can have its own operating system.
Domain 0
CMU 0
• CPU
• DIMM
• IO
Domain 1
CMU 1
• CPU
• DIMM
• IO
Domain 2
CMU 2
• CPU
• DIMM
• IO
Domain 3
CMU 3
• CPU
• DIMM
• IO

27
Figure 2.14 Hypervisor Virtualization
As we can see from hypervisor architecture at least one domain has to control and
serve other LDOMs, this hypervisor domain should not run any application, and then
we can create 3 LDOM’s (guest domain).
2.6.3 Operating System –Virtualization
In this kind of virtualization the operating system provides a shared,
virtualized OS image, including a unique root, a (safely shared) set of system
executable and libraries, and whatever resources assigned to the VM when it is
created.
Physical
CPU
StorageNetworkPhysical
Memory
Hardware
Virtual
CPU
SchedulingVirtual
Memory
CPU
Hypervisor
Domain
guest
Domain
guest
Domain
guest
Hypervisor
Domain

28
Figure 2.15 Operating System –Virtualization
Each virtual operating system (Zone) can be booted and shut down just like a regular
operating system, and rebooted in only seconds when necessary to give you the
fastest reboot ever.
Only one single kernel runs on a physical server. Used by host and guest’s OS.
By OS Virtualization we can consume the existing system resources and use them in
very efficient and transparent manner, so the virtual operating system appears just
like a separate server.
2.7 Virtualization Vs Cloud Computing
The cloud computing is the new buzz word, is this new technology same as
virtualization, no it’s not.
Cloud computing definition based on Gartner is it a service-based, scalable and
elastic, shared, metered by use, and uses internet technologies.
Physical
CPU
StorageNetworkPhysical
MemoryHardware
Local Zone
1
Local Zone
2
Local Zone
3
Global
Domain
Kernel

29
Its sound like the virtualization definition, so unless the ITDC applications are
decoupled from specific server and from underlying operating environments, and the
resource like storage and network is shared among our ITDC we don't have Cloud
Computing. You don't get the efficiencies being touted for it, you don't get the true
elasticity associated with it, and you don't get the performance associated with it."
Virtualization is the key of cloud computing. It’s a tool that helps shape the cloud,
optimizing the allocation of resources and allowing for growth and shrinkage of the
services in the cloud without having to purchase new machines.
By Cloud computing would purchase computing resources from a central pool and
pay as you grow, only for the amount of CPU, RAM, storage and bandwidth that the
user needs.

30
IIICHAPTER‫‏‬
LITERATURE REVIEW
3.1 High Availability Using Virtualization
In this section we will discussed the work that has been conduct in PhD
Thesis about High Availability Using Virtualization. [4]
3.1.1 Idea:
Provide a high availability system - architecture, software, methodology - for
all non-critical services, without charging a computer center with the cost of the
classical heartbeat host per host redundancy.
3.1.2 Tools:
Ganglia monitor, heartbeat, VMware, SAN, Shell script, PXE, Linux and
DRBD.
3.1.3 Solution:
The 3RC application detect the failure from the Ganglia monitor event report
and based on crash algorithm chick failure reason like (an overload of the virtual

31
machine, host unresponsive), and starts the recovery procedure (REBOOT,
RESTART and REINSTALL).

32
3.2 Application Recovery On Various Network Architecture Employing
Solaris Operating System Metadata And Virtualization.
In this section we will discussed the work that has been conduct in Master
Thesis about Application Recovery on Various network Architecture employing
Solaris Operating System Metadata and Virtualization. [5]
3.2.1 Idea:
Provide solution for recovering complex environment the use vitalization
technology in different architecture OS, storage, network and application. And he use
different technology solution to reach to highly available environment using
automatic failover solution (ORACLE HA Cluster).
3.2.2 Tools:
Windows 7 ultimate, VMware server, network attach storage (NAS), Solaris
10, SVM and ORACLE HA Cluster.
3.2.3 Solution:
Use SVM to build raid 1 file system for recovery and virtual file system
umbrella to have scalable and transparent file system structure, and he use IP
Multipathing (IPMP) network technology to provide redundancy and automatic
failover, And he use the most newest technology ORACLE HA Cluster to provide
automatic failover for Operating System (OS) and application also, and this the main
different between this thesis and PhD Thesis, High Availability Using
Virtualization. [3], so the second one doesn’t cover the application failure because
his solution doesn’t have recourse type that work like driver for application.

33
IVCHAPTER
RESEARCH DESIGN AND METHODOLOGY
We describe all planned data gathering and analysis techniques that we used to
approve our thesis goal in this chapter, then will explain each topic in detail in the
next chapters.
Figure 4.1 Methodology
As it showing in the following diagram [Fiqure.4.1], this thesis we start with the
system from the core, which it will describe how we can build SAR (scalable,
available and reliable) main and virtual operating system environments storage by
design and implementing it using SVM or ZFS technologies, then we will describe
design and implement the networks by using different technologies like IPMP and
OS
Network
Zone
File system &
Application

34
aggregation, then design, implement and install numbers of virtual Zones/Containers,
after that we will tune-up the whole virtual environment by controlling the resources
(Memories and CPUs), finally we will test the SAR in different cases like hardware
failure (Storage or Network) or system recovery in case of failure upgrade or update.
4.1 VMware
We used VMware workstation as solution to have hypervisor layer of
virtualization on my laptop, which will help to create a virtual environment; it will
give the ability to install multiple OS on top of windows, and to have multiple
network cards and storages which we can share among the virtual operating systems.
4.2 Solaris (OS)
We use in our study the ORACLE Solaris operating system and use one of its
virtualization type its operating system virtualization (ZONE), we will explain why
we chose the operating and this type in chapter eight.

35
4.3 Network
By VMware software facilities we can define a virtual interface card, which
it’s not physically available in my laptop, but the VMware created virtually.
Create virtual network adaptors by using VMware software facilities, and assign it to
Solaris Operating System.
Design and configure various network techniques:

36
4.3.1 IP Multipathing [IPMP]
I will design multiple network adaptors as a group for redundancy, so if one
adaptor fail the IP address fail over to second adaptor automatically without
interrupting the network access.
4.3.2 Aggregation
It is like the IPMP, but it works in parallel to increase the link speed beyond
the limits of any one single adaptor.
Figure 4.3 Basic Aggregation
Server A
Aggregation
Communication
10.128.51.90
Bge0
Bge1
Online
Server A
IPMP Communication
10.128.51.90
Bge0 10.128.51.91
Bge1 10.128.51.92
Online
Offline
Figure 4.2 Basic IPMP

37
4.4 File System
We used two technologies to build OSFT the first one is USF/SVM (Solaris
Volume Manager) and the second one is new and enhanced technology it’s ZFS.
4.4.1 SVM
We design and implement the system and application files by using Solaris
Volume Manager (SVM) technology, to be mirrored on virtual disks.
We increase the scalability, availability and reliability of the disk, operating system
and virtual operating system (Zone) using Solaris Volume Manager (SVM).
This design and implementation we be explain by details in chapter six.
Figure 4.4 Solaris Volume Manager (SVM) Design
4.4.2 ZFS
This new technology we use it to design the system with ZFS pool, its new
file system structure and file system management technology together not like the
old UFS/SVM where UFS is UNIX File System and SVM is Solaris Volume
Manager.
Physical Disks
c0t0d0s0 --> d10
c0t1d0s0 --> d20
Virtual Disk d0
d10 d20

38
The new technology is based on pool design where you can pool all the storage size
on one pool and you use only what you need to save the space and also you can
resize your size online without interruption the user.
In chapter six we will explain how we design and implement ZFS.
4.5 Virtual OS (Zone), Network And File System
We merge all the previews technology together and use it to Design and
implement the SAR virtual OS (Zone) file system, network and storage. In chapter
eight we explain how we configure and install the virtual OS (Zone) based on its
type. And how we make the virtual OS (Zone) fault Tolerant, by making its file
system mirrored and let the virtual OS (Zone) use IPMP technology that design and
built before in main OS.

39
VCHAPTER
DESIGN AND CONFIGURE
SAR NETWORK
The SAR network is very important to design and implement SAR virtual
environments, because the network availability and reliability will impact on all
virtual environments, and the scalability of the network become more important
because it will allow us to have virtual network interface once we need it and without
affecting the other virtual environments.
I will use two technologies to design and implement the SAR virtual environment
first one is IPMP (IP Multipathing) and the second is the Aggregation.
5.1 IPMP (Internet Protocol Multipathing)
IPMP is a feature of Solaris 10, to design and configure highly available
network solution to our physical server and virtual operating systems.
Internet Protocol Multipathing is used to provide automatic failover and outbound
load spreading for network interfaces.

40
5.1.1 Design And Implementation
5.1.1.1 High Available Network Topology
To have highly available network design we have to have highly available
network topology, I will use in my design fully connected topology, the server have
dual ports for redundancy and we network have two network switch for
redundancy.[10]
Figure 5.1 IPMP & High Available Network Topology
5.1.2 IPMP (IP Multipathing) Group
In our design we have server with two NICs (Network Interface Cards) that
are connected to the LAN port0 and port1. And there is a unique IP for port0
(10.128.20.10) and a unique IP for port1 (10.128.20.11) these two interfaces are then
placed in an IPMP group by script and ifconfig command and the IPMP has also a
Port 0
10.128.20.10
ACTIVE
Port 1
10.128.20.11
STANDBY
IPMP
10.128.20.12

41
virtual unique IP (10.128.20.12). So if the active interface, which carries the IP, fails,
then the other interface (standby) will take over the IP address.
Figure 5.2 Probe based IP Multipathing
5.1.3 IPMP Design And Implementation
To configure a multiple network interface in Solaris, we use ifconfig,
command to set it up, and we have to write script that contain the interface name, IP,
netmask, broadcast, IPMP group and other feature about how the IPMP will handling
the errors to make the configuration Permanente.
For IP Multipathing, we need 3 IP addresses. And two network interfaces (e1000g0
and e1000g1) and 1 for the virtual address:
 10.128.20.10 on e1000g0 and this will be the active IP.
 10.128.20.12 on e1000g0:1 will be the virtual IP address for e1000g0.
Port 0
10.128.20.10
ACTIVE
Port 1
10.128.20.11
STANDBY
IPMP
10.128.20.12

42
 10.128.20.11 on e1000g1 will be the IP for the e1000g1 interface.
The network cards in our example are connected to LAN 10.128.20.0 that is
connected to the LAN, I will configure those interface and group it in IPMP group by
the ifconfig command:
 Open the interfaces e1000g0 & e1000g1:
root@TEST # ifconfig e1000g0 plumb
root@TEST # ifconfig e1000g1 plumb
 Assign IP address and netamsk to the interface and bring it up:
root@TEST # ifconfig e1000g0 10.128.20.10 netmask
+broadcast +up
 Create the IPMP group (ipmp0) form e1000g0:
root@TEST # ifconfig e1000g0 group ipmp0
Now e1000g0 is setup with an IP address and put in the ipmp0 group.
 Display the network status after creation the IPMP group (ipmp0):
root@TEST # ifconfig e1000g0
e1000g0:
flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500 index 2 inet 10.128.20.10 netmask ffffff00
broadcast 10.128.20.255 groupname ipmp0
 create virtual IP from NIC e1000g0

43
root@TEST # ifconfig e1000g0 addif 10.128.20.12
netmask + broadcast + -failover deprecated up
We add two options to the configuration failover and deprecated:
Failover: the address assigned to a non-failover logical interfaces will not failover
when the interface fails.
Deprecated: used to disable the load spreading option, this option used with client
and server design, when the client software initiated traffic to the server by using
known interface.
 Display the network status after creation the virtual NIC from e1000g0:
root@TEST # ifconfig –a
e1000g0:
broadcast 10.128.20.255 groupname ipmp0 ether
0:14:4f:9e:e7:b2
e1000g0:1:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATE
D,IPv4,NOFAILOVER> mtu 1500 index 5 inet 10.128.20.12
netmask ffffff00 broadcast 10.128.20.255
e1000g1:
flags=1000842<BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500 index 4 inet 0.0.0.0 netmask 0 ether
0:14:4f:9e:e7:b0

44
From the output we can see the second NIC e1000g1 interface. But it’s without IP
address, we need to configure it and put it in the same IPMP group as e1000g0.
root@TEST # ifconfig e1000g1 10.128.20.12 netmask + broadcast +
up
root@TEST # ifconfig e1000g1 group ipmp0 -failover deprecated
root@TEST # ifconfig -a
e1000g0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu
1500 index 5 inet 10.128.20.12 netmask ffffff00 broadcast
10.128.20.255 groupname ipmp0 ether 0:14:4f:9e:e7:b2
e1000g0:1:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOF
AILOVER> mtu 1500 index 5 inet 10.128.20.12 netmask ffffff00
broadcast 10.128.20.255
e1000g1:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOF
AILOVER> mtu 1500 index 4 inet 10.128.20.11 netmask ffffff00
broadcast 10.128.20.255 groupname ipmp0 ether 0:14:4f:9e:e7:b0
To test our configuration I will use if_mpadm to disable the first NIC e1000g0, and
see failover status.
root@TEST # if_mpadm -d e1000g0
 Display the network status after disable NIC e1000g0:
root@TEST # ifconfig –a

45
e1000g0:
flags=89000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAIL
OVER,OFFLINE> mtu 0 index 2 inet 0.0.0.0 netmask 0
groupname ipmp0 ether 0:14:4f:9e:e7:b2
e1000g0:1:
flags=89040842<BROADCAST,RUNNING,MULTICAST,DEPRECATED,
IPv4,NOFAILOVER,OFFLINE> mtu 1500 index 2 inet
10.128.20.12 netmask ffffff00 broadcast 10.128.20.255
e1000g1:
flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATE
D,IPv4,NOFAILOVER> mtu 1500 index 3 inet 10.128.20.11
netmask ffffff00 broadcast 10.128.20.255 groupname
ipmp0 ether 0:14:4f:9e:e7:b0
e1000g1:1:
broadcast 10.128.20.255
The virtual NIC e1000g1:1 has been created automatically after disabling the
e1000g0 with same IP address 10.128.20.10 .
All these command and configuration we did it online and it’s not permanent, to
make it permanent we have to write script contain these setting and design, and we
have to update one of the system file.

46
In order to make these deign and configuration permanent we have to do the
following steps:
1. Add the following IPs, host name and NIC in /etc/hosts file:
10.128.20.12 TEST TEST. loghost
10.128.20.10 TEST.e1000g0
10.128.20.11 TEST.e1000g1
2. Create two files contain the script and design of the NICs e1000g0 and
e1000g1:
a. First file will be hostname.e1000g0 under etc and
contain the following script:
TEST netmask + broadcast + group ipmp0 up
addif TEST.e1000g0 netmask + broadcast + deprecated -
failover up
b. Second file will be hostname.e1000g1 under etc and contain the
following script:
TEST.e1000g1 netmask + broadcast + group ipmp0
deprecated -failover up
3. Reboot the server and the system will come by highly available IPMP design.
5.2 Aggregation
A link aggregation consists of several interfaces on a system that are
configured together as a single, logical unit.in active – active mode, it is defined in
the IEEE 802.3ad Link Aggregation Standard. [10]

47
5.2.1 Aggregation Feature
The following are features of link aggregations:
 Increased bandwidth – The capacity of multiple links is combined into one
logical link.
 Automatic failover/failback – Traffic from a failed link is failed over to
working links in the aggregation.
 Load balancing – Both inbound and outbound traffic is distributed according to
user selected load-balancing policies, such as source and destination MAC or IP
addresses.
 Support for redundancy – Two systems can be configured with parallel
aggregations.
 Improved administration – All interfaces are administered as a single unit.
 Less drain on the network address pool – The entire aggregation can be
assigned one IP address.
It is useful to use aggregation in some situations like NFS (network file system)
server to distributed heavy traffic, Or for DB server that connect to many connected
web pages, or if you want to hide the server MAC address for a security reason.

48
Figure 5.3 link aggregation topology
5.2.2 Aggregations Requirements
Aggregation support only interfaces that work in same speed and in full-duplex
mode and we have to set value of the system parameters MAC address to true.
 Display the available NICs and its mode and speed we use “ dladm show-dev ”
command:
bash-3.00# dladm show-dev
e1000g0 link: up speed: 1000 Mbps duplex: full
bash-3.00#
The NICs e1000g0, e1000g1 and e1000g2 are the available NICs in my system.
Port 0 ACTIVE
aggr1
10.128.20.12
Port 1 ACTIVE
Port 2 ACTIVE

49
Check the system MAC address setup for SPARC server only the X86 server its
TRUE, we use “ eeprom local-mac-address? ” command:
uss15@dnuspc01 # eeprom local-mac-address?
local-mac-address?=true
5.2.3 Aggregation Design And Implementation
Before we create the aggregation group we have to prepare the NICs that we will
use it for aggregation, those NICs should un-plump or its link status should be
unknown, use the following command to un-plump the NICs and to display the link
status:
 Un-plump the NICs
bash-3.00# ifconfig e1000g0 unplumb
 display the link status
bash-3.00# dladm show-dev
e1000g0 link: unknown speed: 1000 Mbps duplex: full
Now the NICs e1000g0, e1000g1 and e1000g2 are ready for aggregation group, to
group it we will use the following steps:
 Create the aggregation group and add the e1000g0 NIC to the group:

50
bash-3.00# dladm create-aggr -d e1000g0 1
 Display the aggregation group status:
bash-3.00# dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:c:29:5e:22:c4 (auto)
device address speed duplex link state
e1000g0 0:c:29:5e:22:c4 1000 Mbps full unknown standby
The aggregation group has created successfully and contain e1000g0 NIC, and we
can see the MAC address of aggregation group and the e1000g0 is same, because we
set the local-mac-address?=true, but the link status is unknown, to make it online we
have to set aggregation group by the following steps:
bash-3.00# ifconfig aggr1 plumb up
bash-3.00# ifconfig aggr1 dhcp * this is only if you want DHCP *
 Display the aggregation group status after configuration:
bash-3.00# ifconfig –a
aggr1:
flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu
1500 index 2 inet 192.168.94.191 netmask ffffff00 broadcast 192.168.94.255
ether 0:c:29:5e:22:c4
We can see from the output that the status is up and the DHCP services assign IP
address to the aggregation group aggr1.
bash-3.00# dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:c:29:5e:22:c4 (auto)

51
e1000g0 0:c:29:5e:22:c4 1000 Mbps full up attached
The status link is up for the NIC e1000g0 in the aggr1.
In the UNIX environments, the live changes to the network interface properties are
NOT permanent to keep it after a reboot. You need to apply these changes to the
relevant boot-level configuration file; we need to create the following file:
bash-3.00# touch /etc/hostname.aggr1
bash-3.00# touch /etc/dhcp.aggr1

52
5.3 IPMP And Aggregation
IPMP and link aggregation are different technologies that offer improved
performance and high network availability.
Table 5.1 Aggregation Vs IPMP
Aggregations IPMP
Configured and mange by dladm and
ifconfig command
Configured and mange by ifconfig tools
Standby interfaces modes are not support
unless a failure is detected. Once the
interface is joined to the group and healthy
will be used.
Support online and offline mode
Use one MAC address Each interface use its own MAC address
Support outbound and inbound load
balancing
Support outbound load balancing only
Easy to administrate More difficult to administrate the
aggregation
Support some NIC types Support all NIC

53
VICHAPTER
DESIGN, CONFIGURE AND IMPLEMENT
SOLARIS VOLUME MANAGER (SVM)
To have highly available operating system, we have to keep our operating
system in away from hardware or software failure, hard ware failure could happed
due to disk failure in this what we will discuss in this chapter, but software failure
could happened because of patching or upgrade and this will be discussed in the next
c h a p t e r .
To manage the files in the UNIX Solaris we have to file system structured UFS
“UNIX File System” or ZFS “Zeta File System”.
Its disk management software is built in Solaris operating system, and it’s called
SVM (Solaris Volume Manager). We use it to manage the UFS “UNIX File System”
file system. [4][5][12]
6.1 SVM Requirement
I will use this SVM to create raid 1 or mirror of two disks which will contain
the operating system, as its list it in the figure we have two disks c0d0 and c2t0d0:

54
Figure 6.1 Available Disk
Actually, I will create a mirror between two slices (partitions) of two disks, Because
we partitions the operating system disk “c0d0” to slices for root, swap, var and
metadb. As following figure:
Figure 6.2 UFS Disk Partitions
We have a server with two hard disks, the device names is /dev/dsk/c0d0 and
/dev/dsk/c2t0d0.
To mirror the two disks the slice partitions structure should be identical, to prevent
the human mistake we can use the following command:
prtvtoc /dev/rdsk/c0d0 s2 | fmt hard -s - /dev/rdsk/c2t0d0s2
To use SVM we have to create the metadb “meta Data Base”, it’s like SVM
database, logs all SVM design and implementation, I will use slice 7 for metadb.

55
In the previous UFS disk partitions figure we can see what and where all the needing
slices are going to be, I will list like the following:
 Root in slice 0
 Swap in slice 1
 Var in slice 3
 Metadb in slice 7
6.2 SVM Implementation
6.2.1 SVM Metadb
After applying same partitions structured on both disks, we do the following
steps to create the raid 1 using SVM metadb (Meta Database), which will reside on
s l i c e 7 :
metadb –a –c 3 -f c0d0s7 c2t0d0s7
We are issuing the metadb command, the -a to add databases, the -c 3 to add three
copies (in case one gets corrupted), and the -f option is used to create the initial state
database.
See the following output after creation the metadb:

56
Figure 6.3 Meta Data Base Status
6.2.2 SVM Metadevice
After our meta databases is setup, we will start to create the mirror disk for
the operating system root, swap and var, we need to tell the SVM software to create a
meta device using that root partition, which will then be paired up with another meta
device that represents the root partition of the other disk to make the mirror.
Figure 6.4 SVM Design
In my design I will use the following met devices names with metainit command as
following:
1. root slice will be d10 and d20:
metainit -f d10 1 1 c0d0s0
Physical Disks
c0d0s0 --> d10
c2t0d0s0 --> d20
Virtual Disk d0
d10 d20

57
metainit -f d20 1 1 c2t0d0s0
2. swap slice will be d11 and d21:
3. var slice will be d13 and d23:
We use –f option because we already have an operating system, and we use 1 1 to
select one to one connection between met device and the disk slice.
6.2.3 SVM Mirror
After we create the metadb and we create the metadevice name and
connected to the disk slices, we can start the mirroring between those metadevices by
issuing the metainit command with –m option, like the following:
metainit d0 -m d10
metainit d1 -m d11
metainit d3 -m d13
Again, we use the metainit command, this time using -m to indicate we are creating a
mirror called d0, and attaching d10.

58
Figure 6.5 SVM Root Mirror 1'st Side
After we creating what we can call it as the first leg of the mirror, we can check the
SVM configuration and status of our system by using metastat command with –p
option, check the following report:
Figure 6.6 Metadevice Design
I will go back one step to check our operating system without SVM, the our
operating boot from c0d0s0 the current root location, but next time we want the root
to come up from d0 not c0d0s0, to do that we will issue the metaroot command to
update the operating system bootable parameter:
metaroot d0
after this command we can see the update in the tail of /ets/system file, by the
following script:
Physical Disks
c0d0s0 --> d10
Virtual Disk d0
d10 ---

59
bash-3.00# tail /etc/system |grep "root"
See the following screen shoot of the /etc/system file change:
Figure 6.7 Metaroot D0 And System File
and I use d0 not d10, to use the virtual name not physical one d10 so iff we add the
second leg d20 the operating system can boot from any one of them d10 or d20 for
redundancy.
Now we will reboot our system to boot from our SVM metadevices d0, d1 and d3
Figure 6.8 OS With SVM

60
As we can see from out put the root “/” is mounted from d0, and swap mounted from
d1 and var mounted from d3.
By this design and by using SVM tools, we build an operating system use virtual
disk like “d0” name rather than using the physical name “/dev/dsk/c0d0s0” for root
as an example, so the system depend on this virtual name, so we can connect more
disk to this name online without interrupting the operating system.
Before we attach the second disk to the umbrella or the virtual disk let’s check the
status of our metadevices before we start the attaching the second disk and mirroring
operation:
Figure 6.9 Metastat Before Attach The Mirror
As we can see the second legs of mirrors it’s not used in any mirroring, only d10,
d11 and d13 is used in the mirroring, we can see “–m” option before these
metadeiveces d10, d11 and d13.
Now we attach the second leg of the mirror by using metattach command:
1. For the root mirror
metattach d0 d20

61
2. for the swap mirror
metattach d1 d21
3. For the var mirror
metattach d3 d23
Display the Meta device structure after attaching the second leg, the mirroring will
start between the mirrored metadevice like d10 and d20 under d0, and we can see
that by issuing metastat command, check the following output:
Figure 6.10 Metastat After Attach The Mirror
And we can check the status of the metadvices by using the metastat command with
metadevice name, the metastat report well gave us the report about the metadvices
health status, mirroring progress, action if needed and disk name, see the following
report about our root metadevice “d0”:

62
Figure 6.11 Root Metadevice Mirror

63
VIICHAPTER
ZFS
ZFS is a new kind of file system that provides simple administration,
transactional semantics, end-to-end data integrity, and immense scalability. Its file
system structure and management not like old file system in Solaris UFS and SVM
(Solaris Volume Management) to administrate the UFS file system.
7.1 Why ZFS?
It’s an improvement of 20 years old file system and management technology
UFS and SVM, new source code for ZFS has been written to replace the old source
code for UFS and SVM, to remove the complicity of 20 years of ongoing
development, because of update after update and feature after feature being added it
system. Even the smallest changes can have wide ranging effects, resulting in a huge
amount of testing and inevitable panics and escalations. [13][14]
The following comparison between the codes in kernel and user components that has
been used to support the old file system structured UFS, SVM (Solaris Volume
Management) and ZFS the new file structured and management. [14][15]

64
Table 7‫‏‬VII.1 UFS, SVM And ZFS Source Code Size
COMPONENT UFS SVM ZFS
KERANL 46806 75917 50239
USER 40147 161984 21073
TOTAL 86953 237901 71312
As we can see from the table, SVM has 161984 lines of codes only on user
component which it’s twice more than the all ZFS code (kernel and user) put
together!
The ZFS introduce pooled model to solve the partition sizing problem or nightmare
in old technology UFS and SVM, be using pooled model we eliminates the concept
of volumes and the associated problems of partitions, provisioning and wasted space.
All file systems can create from a common storage pool, each one consuming only as
much space as it actually needs, to save space and money.
7.2 ZFS Architecture
One or more Storage devices can be grouped as a ZFS pool, and one or more
ZFS file systems could be created in the ZFS pool. The DISK could be local storage
disk or “SAN storage attached network” as a ZFS pool.

65
Figure 7.1 ZFS Pool
We can create ZPOOL from four virtual disks I created in my VM, my virtual disk
names and size is:
1. c2t1d0 size = 1GB
I will create ZPOOL consist of disks c2t1d0 and c2t2d0, the total size of this ZPOOL
will be 2GB, to create the ZPOOL we use ZPOOL create as following:
zpool create TEST1 c2t1d0 c2t2d0
To list the existing system ZPOOL we use ZPOOL list:
DISK DISKDISKDISK
ZPOOL

66
Figure 7.2 ZPOOL list
To check the status of existing ZPOOL in our system like “TEST1” we use the status
option in ZPOOL command, like the following figure:
Figure 7.3 ZPOOL Status

67
7.3 ZFS HA Design
To design highly available file system design we need to create raid1 on the
ZFS POOL, ZFS provide this feature by using mirror option, we can apply mirroring
on existing ZPOOL without interrupting the system.
Figure 7.4 ZFS Mirror “RAID1”
We need two local disks or SAN storage “LUNs” to do mirroring or RAID1, to apply
the mirroring we use the mirror option in ZFS tools.
To simulate this mirroring we add two virtual disks in Virtual machine by using
VMware tools, and use these virtual disks c2t3d0 and c2t4d0 like the following:
DISK Mirror
DISK
ZPOOL

68
bash-3.00# zpool create TEST2 mirror c2t3d0 c2t4d0
Figure 7.5 RAID1 ZPOOL Status

69
VIIICHAPTER
DESIGN, CONFIGURE AND INSTALLATION
ORACLE SOLARIS VIRTUALIZATION
The information technology expands the scale of the IT infrastructure to
decrease the implementation time and to increase the efficiency. The virtualization is
wildly used to reduce the cost of information technology infrastructure, and to
increase the resource optimization.
The Oracle Solaris operating system is support many kind of virtualization like
others can do, but it has a unique type that no one else until now provide it its
operating system virtualization, and by using SVM or ZFS for storage virtualization,
and by using IPMP or Aggregation for network Multipathing we can increase the
SAR for these virtualized environment. [13]

70
8.1 Oracle Solaris Virtualization Type
Three kinds of virtualization is supported in oracle Solaris operating system,
each type has its own design, advantages and disadvantages.
Figure 8.1 Oracle Solaris Virtualization
1. Domain “Hard Partition”:
Hard ware virtualization, the CPU/Memory Board Unit (CMU) can be
logically partition to assign memory, CPU or network card to each domain. In
this type no sharing on hardware or operating system level, so each domain is
independent.
2. Logical Domain “LDOM”:
Logical domain is like hypervisor layer, and the LDOM manager is enabled
and initializes the first domain as the control domain. To create, shutdown,
configure, and destroy other domains. The control domain can also be
configured as an I/O domain, which has direct access to I/O devices and
provides services for other domains to access I/O devices. The CPU, memory
and input/output devices are flexibly allocated by the LDOM manager.

71
3. Zone “Operating System Virtualization”:
Solaris Zones are an operating system abstraction for partitioning servers,
allowing multiple guest operating systems to run in isolation from each other
on the same host operating system on the same server. This isolation prevents
user within a zone from monitoring or affecting other user in other zones, so
the data and hosing operating system setting is highly secured. [11][12]
Zones also provide an abstraction layer that separates applications from
physical attributes of the machine on which they are deployed, such as
physical device paths and network interface names. [16]
Figure 8.2 Zone Architecture
In operating system virtualization there will be two kinds of zone global and
local zone:

72
 Global Zone: Refers to the host Solaris operating system instance
installed on the physical server.
 Local Zone: Refers to an isolated copy of the Solaris operating system
running as a child of the Global Zone. There is other user term for this
kind as non-global or zone.
8.2 Why Zone?
In the information technology infrastructure there is a lot of update, release
and problem fixes of the operating systems, data bases and application yearly. Theses
updates, releases and problem fixes could cause a lot of outages on all the landscape
development, quality insurance and production.
The SAR “scalability, availability and reliability” of the information technology
infrastructure could be impact because of update and new release, those update could
be an emergency or a security update which has to be installed and test it, this could
cause an outages. The Solaris zone has a lot of features that help to control the work
follow of operating systems, data and applications between the landscape
environments and to minimize these outages, and gave us more administration
control.
8.3 Zone Feature
In the following subsections we will list and explain zone feature.
8.3.1 Zone Agility
By using zone feature in the Solaris operating system, we can increase the
agility of the IT Infrastructure to deliver the business need, adding new business

73
require new application, database, storage and network which will take a long time to
deliver the hard ware and license plus implementation time.
By using zone the new server will be virtual server and ready within an hour, all
what we need is global domain ready to host the zones “local domain”.
By using highly available design of the global domain on file system and network
levels and by using zone configuration command we can have highly avalible vertuil
environment “zone”.
8.3.2 Zone Security
To have SAR virtual environment the user of the each zone should have
access only to its Local Zones. In cases where access is required, the virtualization
administrator will work with the zone user to do what require on the Global Zone.
8.3.3 Zone Maintenance
Oracle Solaris standard is to patch the system every 6 months, so if you have
in your landscape three environments development, quality insurance and production
systems.
In non-virtualized environment you will be busy all the year to meet the maintenance
slandered.
Also in virtualized environment Both the Global Zone and Local Zones are subject to
this standard “six-month” patch process, And Local Zones and the services they offer
will be offline during the entire Global Zone patch process. This process will affect
the SAR of the virtualization solution.

74
To increase the SAR of the virtualized environment there is three solution live-
upgrade, Oracle Solaris Cluster and Oracle RAC.
Live upgrade solution will create another complete passive virtual environment and
enable the administrator to upgrade or patch or even migrate, so the only outage we
need is to reboot the server, which will save normally hours of outages and gave us
safe and easy fallback.
By using Oracle Solaris Cluster or Oracle RAC you have to have redundant server as
active-passive or active-active nodes and using shared storage so you can faile over
your zone application to other node or you could have scalable design by using RAC
solution.
8.4 Zone High Availability Network
each zone have its own identity, separate from the underlying hardware, it
behaves as if it's running on its own system making consolidation simple, safe, and
secure. But all these zones will share the network, so if the network card go down all
the zones will be down, because we “put all the eggs on one basket”, so the network
availability become more important.
The zone can use the highly available network solution like IPMP and aggregation,
by creating highly available virtual network card for each zone to increase the SAR
in the consolidate environment.
8.5 Zone High Availability Storage
The virtual environment will share the storage resource as the networks
resources, so we have to have highly available design of our storage resources by

75
using SVM or ZFS and use this design in zones to have highly available solution for
the virtual environment.
By using zone configuration command we can assign the file system to its zone, so
each zone can mount and use only its files.
8.6 Zone Design
It’s too important to have highly available global domain, Because it will host
all the local domain or zones.
After design and implement the highly available network using IPMP or aggregation
design and SVM or ZFS for storage, we can create SAR zones.
The local zone is two types Sparse and Whole Root Zone:
In a Sparse Root Zone, the directories /usr, /sbin, /lib and /platform
will be mounted as loopback file systems, they will be mounted as read-only file
systems. Any change to those directories in the global zone can be seen from the
sparse root zone.

76
Figure 8.3 ZONE Inherited Directories
If your application administrator needs the ability to write into any of those inherited
directories, you may need to configure a Whole Root Zone.
8.7 Zone States Model
Zone can be in one of the following states: [16]

77
Figure 8.4 ZONE States Model
1. Undefined. This is stage where zone configuration was started but not yet
committed to storage or if the zone was deleted.
2. Configured. The zone's configuration is completely specified and committed
(written to disk). However, some elements of the zone's application
environment (root password, etc) that must be specified for the boot are still
missing.
3. Installed. The zone's configuration is completely configured and ready to
boot.
4. Ready. Transition to this state from the installed state is essentially a
switching on VM (like online button in devices).
5. Running. User processes associated with the zone application environment
are running. The zone automatically enters the running state from the ready
state as soon as the first user process associated with the application
environment (init) is created.
Undefined
Configured
InstalledReady
Running
Shutting
down and
down

78
6. Shutting down and down. These states are transitional states that are visible
while the zone is being halted. However, a zone that is unable to shut down
for any reason will stop in one of these states.
8.8 Zone Creation
You need at least 2 gigabyte to hold a newly installed zone. This amount of
the space is required to copy the essential files to the local zone, and we need also IP
for connectivity.
The zone directory should be mirrored as a HA storage using SVM or ZFS.
I will create directory /export/zone to holds my zone file systems, and I will use
aggregation to have HA network solution.
Create the new zone directory zone01 and I have to change its privilege to 700 as
following:
root@VM01 # pwd
/export/zone
root@VM01 # mkdir zone01
root@VM01 # chmod 700 zone01/
root@VM01 # ls –al |grep zone01
drwx------ 2 root root 512 Sep 27 13:45 zone01
Check the HA network interface, I use aggregation as HA solution for two interfaces
e1000g1 and e1000g2:
root@VM01 # ifconfig aggr1

79
aggr1:
flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>
mtu 1500 index 3 inet 192.168.94.193 netmask ffffff00 broadcast
192.168.94.255 ether 0:c:29:c6:c2:24
root@VM01 # dladm show-aggr
key: 1 (0x0001) policy: L4 address: 0:c:29:c6:c2:24 (auto)
e1000g1 0:c:29:c6:c2:24 1000Mbps full up
attached
e1000g2 0:c:29:c6:c2:2e 1000Mbps full up
attached
Configure the zone using zonecfg command as following:
root@VM01 # zonecfg -z zone01
zone01: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:zone01> create
zonecfg:zone01> set zonepath=/export/zone/zone01
zonecfg:zone01> set autoboot=true
zonecfg:zone01> add net
zonecfg:zone01:net> set physical=aggr1
zonecfg:zone01:net> set address=192.168.94.194
zonecfg:zone01:net> end
zonecfg:zone01> verify
zonecfg:zone01> exit

80
Figure 8.5 New ZONE
After configuring the zone we can verify and commit the setting, as following:
root@VM01 # zonecfg -z zone01 verify
root@VM01 # zonecfg -z zone01 commit
Also its useful to export these setting as a script to become as a template we can
use it to create another zone.
root@VM01 # zonecfg -z zone01 export
create -b
set zonepath=/export/zone/zone01
set autoboot=true
set ip-type=shared
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
Development
Storage
zone01

81
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add net
set address=192.168.94.194
set physical=aggr1
end
We can see the inherited pkg from the global zone /lib, /platform, /sbin and /usr.
The new zone zone01 should be now in configured state, to check we use zoneadm
command as following:
root@VM01 # zoneadm list –cv
ID NAME STATUS PATH BRAND
IP
0 global running / native shared
- zone01configured /export/zone/zone01 native shared
Now the new zone is in configured state and ready to be install:
root@VM01 # zoneadm -z zone01 install
Preparing to install zone <zone01>.
Creating list of files to copy from the global zone.
Copying <3314> files to the zone.

82
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <1110> packages on the zone.
Initialized <1110> packages on zone.
Zone <zone01> is initialized.
Installation of <26> packages was skipped.
The file </export/zone/zone01/root/var/sadm/system/logs/install_log>
contains a log of the zone installation.
Now I will verify the state of the new zone, one more time:
root@VM01 # zoneadm list -cv
ID NAME STATUS PATH BRAND IP
- zone01installed /export/zone/zone01 native shared
Now let’s Boot up the new zone “zone01”, and check how the virtual network of the
zone zone01 will appear after booting the zone.
root@VM01 # zoneadm list -cv
ID NAMESTATUS PATH BRAND IP
2 zone01running /export/zone/zone01 native shared
Now the virtual interface card should be created, Check the network status:
root@VM01 # ifconfig -a
lo0:flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VI
RTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000

83
lo0:1:flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,
VIRTUAL> mtu 8232 index 1 zone zone01 inet 127.0.0.1 netmask ff000000
e1000g0:flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHC
P,IPv4> mtu 1500 index 2 inet 192.168.94.192 netmask ffffff00 broadcast
192.168.94.255 ether 0:c:29:c6:c2:1a
aggr1:
flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4>
mtu 1500 index 3 inet 192.168.94.193 netmask ffffff00 broadcast
192.168.94.255 ether 0:c:29:c6:c2:24
aggr1:1:
1500 index 3 zone zone01 inet 192.168.94.194 netmask ffffff00 broadcast
192.168.94.255
As we can see from the output there is virtual network card created from aggr1 and
its name is aggr1:1.
Now we have HA storage for the new zone using SVM and HA network using
aggregation.
8.9 Zone Cloning
We can create repleca of the zone on same machine or on different amchine
using zone cloning option.
We need to export the zone configuration using export option and update some
parameters like IP, zone path and dataset name, etc.

84
To export the zone creation script, use the export option and save to the file as
following:
root@VM01 # zonecfg -z zone01 export >>zone01-export.cfg
We have to edit some setting like new zone path and the IP, as following:
root@VM01 # more zone01-export.cfg
create -b
set zonepath=/export/zone/zone02
set autoboot=true
set ip-type=shared
add inherit-pkg-dir
set dir=/lib
end
add inherit-pkg-dir
set dir=/platform
end
add inherit-pkg-dir
set dir=/sbin
end
add inherit-pkg-dir
set dir=/usr
end
add net
set address=192.168.94.195
set physical=aggr1

85
end
Create a new (empty, non-configured) zone by using the configured exported script
for original zone “zone01”, as following:
root@VM01 # zonecfg -z zone02 -f zone01-export.cfg
root@VM01 # zoneadm list –cv
ID NAME STATUS PATH BRAND IP
0 global running / native
shared
- zone01 installed /export/zone/zone01 native
shared
- zone02 configured /export/zone/zone02 native
shared

86
IXCHAPTER
SOLARIS LIVE UPGRADE
Solaris Live Upgrade is a SUN tool that provides a method of upgrading a
system while the system continues to operate. While your current boot environment
is running, its allow us to have duplicate or alternative boot environment, then we
could maintain or upgrade the alternative boot environment. The original system
remains fully functional and unaffected by the upgrade or maintenance of an
alternative boot environment. [19]
To bring one system down for maintenance is an expensive change in the ITDC;
what about bring system that hosts many virtual operating systems (zones).
Without live upgrade, the system maintenance require to bring all the virtual
operating systems (zones) in halt status, so the outage will affect all the hosted virtual
operating system ( zones ), and normally the Solaris 10 patch take in the system that
has 10 virtual operating systems about 4 hours.
With live upgrade it will be just a few minutes to reboot from the new boot. And one
more excellent advantage is the recovery fallback plan this option if a failure occurs,
you can quickly revert to the original boot environment with a simple reboot.

87
With Solaris Live Upgrade we duplicate a boot environment without affecting the
currently running system. We can then do the following:
 Upgrade a system.
 Change the current boot environment's disk configuration to different file
system types, sizes, and layouts on the new boot environment.
 Maintain numerous boot environments with different images. For example,
you can create one boot environment that contains current patches and create
another boot environment that contains an Update release.
In our SVM design we use two hard disks to have raid1, and we need two more disks
to raid1 in the alternative boot environment, so we need four disk.
We need to install the latest live upgrade package before we start use it, to have the
latest enhanced feature and to prepare the boot environment for live upgrade.
Boot environment Alternative
boot environment
Disk 0 Disk 1 Disk 2 Disk 3
Figure 9.1 Live Upgrade with SVM

88
We will use live upgrade command to create and main the alternative boot
environment, I will list the command that we use: [19]
Table 9.1 Solaris Live Upgrade (Command Reference)
Command Task
luactivate Activate an inactive boot environment.
lucancel Cancel a scheduled copy or create job.
lucompare Compare an active boot environment with an alternative boot
environment.
lumake Recopy file systems to update an inactive boot environment.
lucreate Create an alternative boot environment.
lucurr Name the active boot environment.
ludelete Delete a boot environment.
ludesc Add a description to a boot environment name.
lufslist List critical file systems for each boot environment.
lumount Enable to mount all of the file systems in an alternative boot environment.
This command enables us to modify the files in an alternative boot
environment while that an alternative boot environment is inactive.
lurename Rename a boot environment.
lustatus List status of all boot environments.
luumount Enable to unmount of all the file systems in an alternative boot
environment. to modify the files while its inactive.
luupgrade Upgrade an OS or install a flash archive on an inactive boot environment.

89
9.1 Live Upgrade And SVM
We use the SVM (Solaris Volume Management), to design SAR storage
solution for the Zone (operating system virtualization) environment.
We design solution to mix live upgrade with our SVM design, to have SAR
alternative boot environment.
The alternative boot environment new disks should have same disks partitions
design, and the partition size should be equal or more for increase the partition size if
we need to increase the root size as an example.
Our SVM design is to have an umbrella of d0, d1 and d3, as a virtual name of the
following design.
 D0 is root slice will be d10 and d20
 D1 is swap slice will be d11 and d21
 D3 is var slice will be d13 and d23
We gave the same design of disk partition to the alternative boot environment:
Boot environment
d13
d11
d10
d23
d21
d20d0
d1
d3
Alternative
boot environment
d913
d911
d910
d923
d921
d920d90
d91
d93
Figure 9.2 Alternative Boot Environment SVM Design

90
 D90 is root slice will be d910 and d920
 D91 is swap slice will be d911 and d921
 D93 is var slice will be d913 and d923
We can design and create this SAR storage enviroemnt for alternative boot
environment by using lucreate command, we write the following script to create this
SAR alternative environment.
I will gave name be1 for the current boot environment and be2 for alternative boot
environment:
lucreate -c be1
-m /:/dev/md/dsk/d90:mirror,ufs
-m /:c0t1d0s0,/dev/md/dsk/d910:attach
-m /:c1t1d0s0,/dev/md/dsk/d920:attach
-m -:/dev/md/dsk/d91:mirror,swap
-m -:c0t1d0s1,/dev/md/dsk/d911:attach
-m -:c1t1d0s1,/dev/md/dsk/d921:attach
-m -:shared:swap
-m -:/dev/md/dsk/d999:swap
-m /var:/dev/md/dsk/d93:mirror,ufs
-m /var:c0t1d0s3,/dev/md/dsk/d913:attach
-m /var:c1t1d0s3,/dev/md/dsk/d923:attach
-n be2
Then after we create the be2 (alternative boot environment) successfully, we can
update it or upgrade it while the boot environment up and running, then we can
activate it by using the following command:

91
luactivate –n be2
To check the status of our be1 and be2 environment we use lustatus:
Boot Environment
Now
Is
Complete
Active
Now
Active
On reboot
Can
Delete
Copy
Status
be1 yes yes No no -
be2 yes no yes no -
We can see the status of be1 is active no and status of be2 is inactive, and the active
on reboot we can see that be1 will be inactive and be2 will become active.
By this design and script we need only one reboot to upgrade or maintained our
system, and we safe hours of outages and interrupting.

92
XCHAPTER
RESULT AND ANALYSIS
Because I did my test on my laptop, that has limited in resources like network
cards and storages, I Install VMware, which will help to create a virtual environment,
it will gives the ability to install multiple OS on top of windows.
The outages could be happened because of planned or unplanned outages, unplanned
outage could be on hardware or software level and planed outages could for
maintenance or upgrade or new requirements for network or storage or even new
virtual operating system.
10.1 Unplanned Outage – Storage
I design SAR storage by using UFS/SVM to test the unplanned outage on the
Storage level that could happened because of losing the disk.

93
10.1.1 SAR Storage Design Vs Standard Backup And Restore Design
I will compare my SAR design for storage with system that use traditional
back up process.
In the SAR design I use SVM to create raid1 on two disks d10 and d20, and I gave
the name d0 to virtual disk name.
Figure10.1 HA Storage Design
In the stander design the use traditional back and restore design there will be local
disk and external back up disk.
Figure10.2 Standard Backup and Restore Design
If there is Disk failure in standard design and we were lucky (we have fresh backup),
there will be loose data, Outage and Administration overhead to restore and test.
virtual
disk d0
d10 d20
Server
Disk Backup

94
If there is Disk failure in SAR design we don’t need backup because we use raid1,
there will be no loose of any data, no outage at all and no administration overhead to
restore or test.
Note: I did my test on storage size 100 GB.
Table 10.1 Unplanned Storage Outage Activity
Unplanned failure Standard Design SAR design
Disk
Outage Action Outage Action
4 hour
Administration
involve
0 hour No

95
10.2 Unplanned Outage – Network
In the standard system that doesn’t using virtualization and doesn’t use highly
available solution for network, the failure in the network card for this kind of server
its mean outage even if the server has two ports the administrator should reconfigure
the network, in my the virtual environment the network is very important because
there is many virtual servers depend on it, so my SAR design will provide SAR
network solution by using IPMP or aggregation technology.
Table 10.2 Network Unplanned Outage With And Without SAR Design
Unplanned
failure
Basic SAR design
Network
1 hour
Administration
involve
0 hour No

96
10.3 Planned Outage – Storage
10.3.1 Backup
Planned outage for the storage could be for Backup, in standard backup
design we need an Outage to take offline backup and also Administration overhead.
And in SAR design this backup will be online and with less administration overhead.
Table 10.3 Planned Backup Storage Activity
Planned
failure
Basic SAR design
Backup
1 hour Administration overhead 0 hour
Less
Administration
overhead

97
10.3.2 Replace
To replace or increase the storage size you need a planned outage for the
standard storage design, we need an Outage to take offline backup and also
Administration overhead to replace the storage and to restore the original data on the
new one. And in SAR design this size increasing or storage replacement will be
online and with less administration overhead.
Table 10.4 Planned Replace Storage Activity
Planned
failure
Basic SAR design
Backup
3 hour Administration overhead 0 hour
Less
Administration
overhead

98
10.4 Planned Outage – Operating System
10.4.1 Update & Upgrade:
As the standard form ORACLE Solaris the operating system need two
outages per year for maintenance, for all your servers.
From my practical experience I did an operating system update for server that host
13 virtual operating system; I will compare it with non-virtualized servers.
Table 10.5 Maintenance In Non-Virtualized And In Virtualized Environments
Planned failure 13 Servers non-virtualized
Virtualized server + SAR
Storage
Update
1 hour Backup 0 hour Backup
2 hour Update & Upgrade 2 hour Update & Upgrade
2 hour Restore 0 hour Reboot from mirror
Total
6 hour * 13 servers = 78
hours
2 hour
10.4.2 Live Upgrade
And even we can do more than that by using live upgrade, we can reach to
zero down time for patching migrating from SVM to ZFS or upgrading.
From my practical experience I did an operating system upgrade from Solaris 10
Update 4 to Solaris 10 Update 9, this operating system host 13 zone (virtual
operating system) and this was 5 years jump, the upgrade was successful and cost me

99
only two outages one for prepare the old operating system to work with the new live
upgrade tools and the second to reboot from the upgraded environment.
10.4.3 New Server
To add new business in non-virtualized environment it will take as a standard
in the ITDC (Information Technology Data Center) from 4 to 6 months, a lot of
paper work, and meeting and finance process to Order new server, Space allocation,
Installing, configuration and networks stuff and power consumption. But in the
Virtualized environment it will be just install new virtual OS “zone” with network set
up.
Table 10.6 Virtualization Agility
Planned failure Non - Virtualized Virtualized
Time Action Time Action
New business
6 week Order & Delivery - -
1 Day Data Center setup - -
1 Day Installation & configuration 30 min Install zone
Total 44 Day 30 Min

100
XICHAPTER
CONCLUSIONS AND RECOMMENDATIONS
11.1 Conclusions
The ITDC (information technology data center), focuses on delivering
business continuity, storage efficiency, resource optimization, minimization of
unplanned downtime, and lower labor and hardware costs (CAPEX).
Virtualization enables the ITDC to do more with less. By server consolidation the
underutilized servers can be consolidated to a fewer number of servers that results in
increased utilization ratios and decreased total cost of ownership (TCO).
The hidden cost of virtualization is the OPEX (operation expense); to reduce the
CAPEX you have to invest on OPEX, the virtualization need a special design and
implementation to enable a business to meet each of virtualization objectives, and
some others too.
To have SAR (scalable, available and reliable) virtualized environment you have to
design all the environment layers from networks to storages to the virtual operating
systems to cover and handle the planned and unplanned outages.

101
By using the design and solution I used in my thesis we increase the SAR of the
network in virtual environment by using two solutions IPMP and aggregation and In
the storage by using UFS/SVM and ZFS. And I use those design and solution on
network and storage to build SAR virtual environment.
By using the SAR virtual environment we can provide business continuity, storage
efficiency, resource optimization, and minimization or elimination of planned and
unplanned downtime, and lower labor and hardware costs (CAPEX) through
business-critical application and data availability.
11.2 Recommendations
The operating system that has virtualization option do provide virtualization
but not with fault tolerance option, we have to design and implement the SAR virtual
environment by using technology and tools in storage that the virtual environment
will be use it and on the network to be highly available and to provide virtual
network card to the all virtual environment.
Using Aggregation in the virtual environment network will increase the bandwidth of
the network more than IPMP, because aggregation use all merged NIC bandwidth to
provide more bandwidth and availability.
Using ZFS as a file system structure and management to do more by less, because
the ZFS has a lot of feature like raidz, snapshot, clone, export and import and much
more.
Use Solaris live upgrade to manage the planed outage like update and upgrade, to
have down time for a single non-virtualized server is difficult what about virtualized

Improving SAR of Virtualization Environments

Improving SAR of Virtualization Environments

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (15)

Similaire à Improving SAR of Virtualization Environments

Similaire à Improving SAR of Virtualization Environments (20)

Improving SAR of Virtualization Environments