32,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Achieve the performance, scalability, and ROI your business needs What can you do at the start of a virtualization deployment to make things run more smoothly? If you plan, deploy, maintain, and optimize vSphere solutions in your company, this unique book provides keen insight and solutions. From hardware selection, network layout, and security considerations to storage and hypervisors, this book explains the design decisions you'll face and how to make the right choices. Written by two virtualization experts and packed with real-world strategies and examples, VMware vSphere Design, Second Edition will help you design smart design decisions. * Shows IT administrators how plan, deploy, maintain, and optimize vSphere virtualization solutions * Explains the design decisions typically encountered at every step in the process and how to make the right choices * Covers server hardware selection, network topology, security, storage, virtual machine design, and more * Topics include ESXi hypervisors deployment, vSwitches versus dvSwitches, and FC, FCoE, iSCSI, or NFS storage Find out the "why" behind virtualization design decisions and make better choices, with VMware vSphere Design, Second Edition, which has been fully updated for vSphere 5.x.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 1136
Veröffentlichungsjahr: 2013
Ähnliche
Table of Contents
Cover
Title
Copyright
Publisher's Note
Dedication
Acknowledgments
About the Authors
Introduction
Who Should Read This Book
What You Need
What's Inside
How to Contact the Authors
Chapter 1: An Introduction to Designing VMware Environments
What Is Design?
The Facets of vSphere Design
The Principles of Design
The Process of Design
Summary
Chapter 2: The ESXi Hypervisor
Evolution of the vSphere Hypervisor
ESXi Design
ESXi Deployment
Upgrading ESXi
Migrating from ESX
Postinstallation Design Options
Management Tools Overview
Summary
Chapter 3: The Management Layer
Reviewing the Components of the Management Layer
Examining Key Management Layer Design Decisions
Creating the Management Layer Design
Summary
Chapter 4: Server Hardware
Hardware Considerations
Server Components
Preparing the Server
Scale-Up vs. Scale-Out
Blade Servers vs. Rack Servers
Alternative Hardware Approaches
Summary
Chapter 5: Designing Your Network
Examining Key Network Components
Exploring Factors Influencing the Network Design
Crafting the Network Design
Design Scenarios
Looking to the Future
Summary
Chapter 6: Storage
Dimensions of Storage Design
Designing for Capacity
Designing for Performance
Local Storage vs. Shared Storage
Choosing a Protocol
Multipathing
vSphere Storage Features
Summary
Chapter 7: Virtual Machines
Components of a Virtual Machine
Sizing Virtual Machines
Virtual Machine CPU Design
Virtual Machine Memory Design
Virtual Machine Storage Design
Virtual Machine Network Design
Guest Software
Clones, Templates, and vApps
Virtual Machine Availability
vCenter Infrastructure Navigator
Summary
Chapter 8: Datacenter Design
vSphere Inventory Structure
Clusters
Resource Pools
Distributed Resource Scheduling
High Availability and Clustering
Summary
Chapter 9: Designing with Security in Mind
Why Is Security Important?
Separation of Duties
vCenter Server Permissions
Security in vCenter Linked Mode
Command-Line Access to ESXi Hosts
Managing Network Access
The DMZ
Firewalls in the Virtual Infrastructure
Change Management
Protecting the VMs
Protecting the Data
Cloud Computing
Auditing and Compliance
Summary
Chapter 10: Monitoring and Capacity Planning
Nothing Is Static
Building Monitoring into the Design
Incorporating Capacity Planning in the Design
Summary
Chapter 11: Bringing a vSphere Design Together
Sample Design
Examining the Design
Summary
Chapter 12: vCloud Design
Differences between Cloud and Server Virtualization
Role of vCloud Director in Cloud Architecture
vCloud Director Use Cases
Components of the vCloud Management Stack
vCloud Cell and NFS Design Considerations
Management vs. Consumable Resources
Database Concepts
vCenter Design
vCloud Management: Physical Design
The Physical Side of Provider Virtual Datacenters
The Logical Side of Provider Virtual Datacenters
Network Pool Decisions
External Networks
Designing Organizations, Catalogs, and Policies
Correlating Organizational Networks to Design
End Users and vApp Networking
Designing Organization Virtual Datacenters
Multiple Sites
Backup and Disaster Recovery
Summary
Index
End User License Agreement
Pages
cover
iii
iv
v
vi
vii
viii
ix
x
xxi
xxii
xxiii
xxiv
iii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
305
306
308
307
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
Guide
Cover
Table of Contents
Begin Reading
List of Illustrations
Chapter 1: An Introduction to Designing VMware Environments
Figure 1.1 The different parts of VMware vSphere design are merely facets of a larger entity.
Figure 1.2 The functional requirements unify the different facets of the design.
Figure 1.3 Functional requirements and design decision points are interdependent.
Figure 1.4 Each facet of the design primarily addresses a different type of decision, such as who, what, or how.
Figure 1.5 The technical facet includes the “what” decisions that are familiar to many IT professionals.
Figure 1.6 The “who”-focused decisions of a VMware vSphere design fall into the organizational facet.
Figure 1.7 Decisions about how you'll operate a VMware vSphere environment fall into the operational facet.
Figure 1.8 Each decision forces other decisions in a complex decision tree. The results of each decision must be compared against the functional requirements.
Chapter 2: The ESXi Hypervisor
Figure 2.1 Typical partition layout of ESXi Installable on a local disk (minimum 5.2 GB)
Figure 2.2 ESXi text installer
Figure 2.3 Deployment options and the resulting boot images
Figure 2.4 Lockdown mode
Figure 2.5 DCUI interface
Figure 2.6 ESXi Shell console
Figure 2.7 Web browser access to configuration and log files
Chapter 3: The Management Layer
Figure 3.1 vSphere Update Manager requires an additional ODBC connection.
Figure 3.2 This configuration file supplies the necessary parameters for vCLI commands.
Figure 3.3 This diagram provides a conceptual overview of vCenter Server Heartbeat.
Figure 3.4 LDP shows the data found in a vCenter LDS instance.
Figure 3.5 You can also use ADSI Edit to connect to a vCenter LDS instance.
Figure 3.6 ADSI Edit shows the different vCenter LDS naming contexts.
Figure 3.7 The vCenter statistics configuration has a profound impact on database size.
Chapter 4: Server Hardware
Figure 4.1 Example of a power and cooling estimation tool
Figure 4.2 How memory is reclaimed
Figure 4.3 Host sizing cycle
Chapter 5: Designing Your Network
Figure 5.1 Link aggregation without MLAG can't offer full redundancy.
Figure 5.2 MLAG support offers both link redundancy and switch redundancy.
Figure 5.3 Systems in a PVLAN can only communicate with certain other nodes.
Figure 5.4 Use multiple connections from separate NICs in your ESXi hosts to separate switches for maximum redundancy.
Figure 5.5 This ESXi host uses two management ports for redundancy.
Figure 5.6 This ESXi host has one management port but uses two NICs for redundancy.
Figure 5.7 Configuring NIC teaming at the guest OS level often isn't the best way to provide redundancy.
Figure 5.8 This configuration uses link aggregation for both the ESXi host and the storage array.
Figure 5.9 Without link aggregation, NFS redundancy requires multiple datastores and multiple VMkernel interfaces.
Figure 5.10 esxtop is showing a normal network load on an ESXi host's management port.
Figure 5.11 When converting a VM, esxtop shows heavy usage of the management port.
Figure 5.12 This Figure shows a sample configuration with two NICs.
Figure 5.13 This ESXi host has two vSwitches, each with two uplinks.
Figure 5.14 A six-NIC configuration provides redundancy for all components.
Figure 5.15 A configuration with eight NICs provides both redundancy and scalability.
Chapter 6: Storage
Figure 6.1 Capacity versus redundancy
Figure 6.2 Performance examples
Figure 6.3 Path Selection drop-down
Figure 6.4 iSCSI multipathing vSwitch
Figure 6.5 iSCSI multipathing port binding
Figure 6.6 Storage DRS threshold settings
Chapter 7: Virtual Machines
Figure 7.1 VM Summary tab in the vSphere 5.1 Web Client
Figure 7.2 Adding devices : to a VM
Figure 7.3 Virtual machine hardware
Figure 7.4 CD/DVD drive hardware options
Figure 7.5 Video card : hardware options
Figure 7.6 Serial port : hardware options
Figure 7.7 General options
Figure 7.8 Remote Console Options
Figure 7.9 VMware Tools options
Figure 7.10 Boot Options
Figure 7.11 Advanced options
Figure 7.12 vCPU settings
Figure 7.13 Memory hardware options
Figure 7.14 Disk options
Figure 7.15 Disk provisioning types
Figure 7.16 VM Startup: /Shutdown
Figure 7.17 VM monitoring
Figure 7.18 MSCS VMs using VM/Host DRS groups in an HA cluster
Figure 7.19 Infrastructure Navigator : displaying the interdependencies between VMs
Chapter 8: Datacenter Design
Figure 8.1 vSphere Home dashboard
Figure 8.2 vCenter Home Inventory Trees and Lists
Figure 8.3 Hierarchy of vCenter Inventory Lists objects
Figure 8.4 vCenter structural example
Figure 8.5 Resource pool settings
Figure 8.6 DRS Automation levels
Figure 8.7 VM Overrides options
Figure 8.8 DRS summary in the Windows Client
Figure 8.9 DRS summary in the Web Client
Figure 8.10 DRS affinity rules
Figure 8.11 DRS Groups
Figure 8.12 DPM Power Management
Figure 8.13 HA settings
Figure 8.14 HA Virtual Machine Options
Figure 8.15 Admission Control policies
Figure 8.16 HA Advanced Runtime Info
Figure 8.17 VM Monitoring
Figure 8.18 Datastore Heartbeating
Figure 8.19 FT summary
Chapter 9: Designing with Security in Mind
Figure 9.1 The number of VMs deployed will only increase in the future.
Figure 9.2 vCenter Server allows you to create a role that can only reset a VM.
Figure 9.3 Very granular permissions can be combined to create a limited user role.
Figure 9.4 The per-site permission structure is one way to handle permissions in Linked Mode environments.
Figure 9.5 To protect specific areas within linked vCenter Server instances, use the No Access permission.
Figure 9.6 The global permission structure uses broad roles that are applicable across multiple Linked Mode instances.
Figure 9.7 By default, the ESXi Shell and SSH access are disabled.
Figure 9.8 Lockdown Mode can be enabled using the vSphere Web Client.
Figure 9.9 This traditional DMZ environment uses separate physical hosts and : physical firewalls.
Figure 9.10 This virtualized DMZ uses VMs and physical firewalls.
Figure 9.11 In this configuration, a single host (or cluster) spans multiple security zones.
Figure 9.12 A fully collapsed DMZ employs both VMs and virtual security appliances to provide separate security zones.
Chapter 10: Monitoring and Capacity Planning
Figure 10.1 vCenter Server's alarms functionality can alert on many different conditions in the virtualized environment.
Figure 10.2 vCenter Server offers both standard and custom performance charts to provide the specific information administrators need to see.
Figure 10.3 VMware Tools adds VMware-specific performance objects and counters to virtualized Windows Server instances.
Figure 10.4 vCenter Operations provides both high-level monitoring functionality and the ability to drill down into specific areas for more information.
Chapter 11: Bringing a vSphere Design Together
Figure 11.1 A hybrid network configuration for XYZ's vSphere environment
Figure 11.2 A potential configuration for XYZ using vSphere standard switches instead of a VDS
Chapter 12: vCloud Design
Figure 12.1 There are many dependencies in the vCloud Director stack.
Figure 12.2 vCloud Director relies on a 1:1 : mapping of vCenter Server to a vCNS Manager server.
Figure 12.3 As your cloud : continues to grow, so must your management footprint.
Figure 12.4 An existing : management : cluster can be used for vCenter design.
Figure 12.5 vCenter design can rely on a single management infrastructure.
Figure 12.6 Adopting converged infrastructure with an integrated vCenter into vCloud Director
Figure 12.7 Provider vDCs are the resources for deployment of vApps in vCloud Director.
Figure 12.8 Storage capability is an easy differentiator for service levels.
Figure 12.9 RAID type can be an acceptable form of differentiating service levels but isn't recommended.
Figure 12.10 Dynamic movement of blocks can dictate levels of performance.
Figure 12.11 Cluster together hosts with similar CPU speeds, and create offerings based on processing power.
Figure 12.12 Use replication as a value added to types of offerings.
Figure 12.13 Stretched clusters can give an offering a lower recovery point objective (RPO) and help avoid disasters.
Figure 12.14 vCloud 1.5.1 and earlier couldn't use storage profiles; therefore, : deploying vApps was unintelligent and used any : datastore available to a cluster of hosts.
Figure 12.15 Choosing a storage profile type allows better utilization : of the server environment.
Figure 12.16 VASA integration can natively define datastore characteristics.
Figure 12.17 A storage profile depends on : datastore : capabilities. You can use datastore clusters to group similar datastores.
Figure 12.18 Create easily : understood names for storage profiles.
Figure 12.19 The easily : understood names make it easier for an end user to choose where to deploy vApps in vCloud Director
Figure 12.20 An external network is a shared-services network. All vApps that bind to this network can communicate with one another.
Figure 12.21 Selecting the Retain IP/MAC Resources check box enables the vApp to consistently maintain the same IP characteristics even after you power off the vApp.
Figure 12.22 Enabling overlapping networks lets you create multiple external networks using the same VLAN.
Figure 12.23 Create a short name for an organization so it can be easily remembered.
Figure 12.24 Allowing an : organization to publish catalogs to all organizations gives the organization the ability : to create global catalogs accessible to all tenants in the cloud.
Figure 12.25 Organization : internal networks are isolated from communication to any external networks. Only vApps connected to this network can : communicate with each other.
Figure 12.26 Connecting a vApp to an organization direct-connect external network allows the vApp to maintain the : characterization of a vSphere port group while still being managed by vCloud Director.
Figure 12.27 Organization routed external : networks use an Edge gateway device to allow Layer 2 isolated networks to access an external network through NAT and firewall rules.
Figure 12.28 Two organizations can share the same external network but are logically separated by Edge gateway appliances. This allows multitenancy in the cloud.
Figure 12.29 A direct vApp network consumes ports and IP addresses on the organization : network it's : connected to.
Figure 12.30 A fenced vApp : creates an identical copy of an existing vApp and inherits the same IP and MAC addresses but is front-ended by an Edge appliance to communicate on : a network without : experiencing overlapping IP addresses.
Figure 12.31 A routed vApp : network uses an Edge device to : create an additional layer of security by allowing an end user to maintain firewall rules for their specific vApp when connecting to a particular organization network.
Figure 12.32 Isolated vApp networks allow vApps to communicate only with each other without connecting to an organization network. A VM can be given multiple NIC interfaces that can be connected to any type of organization network.
Figure 12.33 A reservation pool model guarantees a percentage of resources to the Org vDC from the backing Provider vDC.
Figure 12.34 An allocation : pool model will guarantee a : percentage of resources to the Org vDC from the backing Provider vDC but also allow : consumption of unallocated resources.
Figure 12.35 A pay-as-you-go pool model sets guarantees on the VMs that are provisioned to a Provider vDC in an Org vDC.
Figure 12.36 Storage profiles dictate the class : of service or I/O characteristics that can be given to a particular Org vDC. The Org vDC must be allocated a certain amount of storage as well, for provisioning vApps.
Figure 12.37 Network pools must : be allocated to an Org vDC for the provisioning of networks in vCloud Director such as organization routed external networks, organization internal networks, vApp routed networks, and vApp isolated networks.
Figure 12.38 If you're using organization routed external networks, an Edge gateway device must be configured to allow access to the : external networks.
Figure 12.39 vCloud 5.1 allows the sharing of : organization : networks between multiple Org vDCs when backed by a single Provider vDC in an organization.
List of Tables
Chapter 2: The ESXi Hypervisor
Table 2.1 Components that provide system state to stateless hosts
Table 2.2 Lockdown mode impact
Table 2.3 ESXi host firewall requirements
Chapter 3: The Management Layer
Table 3.1 vCLI syntax as compared to console syntax
Table 3.2 vCLI authentication precedence
Table 3.3 Example for vSphere environment
Table 3.4 Risk mitigation for a virtual vCenter Server
Table 3.5 Functions not available when vCenter fails
Table 3.6 Recommendations for optimal performance
Table 3.7 Results from Update Manager Sizing Estimator
Table 3.8 VMware recommendations for database performance with Microsoft SQL Server 2008
Chapter 4: Server Hardware
Table 4.1 Memory overheads for common VM configurations
Table 4.2 Memory reclamation levels
Table 4.3 PCI bus speeds
Chapter 5: Designing Your Network
Table 5.1 How
not
to assign IP addresses
Table 5.2 Standardized IP addresses
Chapter 6: Storage
Table 6.1 The 9s
Table 6.2 Average IOPS per disk type
Table 6.3 Protocol hardware characteristics
Table 6.4 vSphere feature comparison for each protocol
Chapter 7: Virtual Machines
Table 7.1 VM hardware compatibility
Table 7.2 Virtual machine hardware maximums
Table 7.3 vNIC features
Table 7.4 VM availability options
Table 7.5 Microsoft clustering disk options (items in bold show VMware's recommended option)
Chapter 9: Designing with Security in Mind
Table 9.1 VMware vShield product comparisons
VMware vSphere® Design
Second Edition
Forbes Guthrie
Scott Lowe
Acquisitions Editor: Mariann Barsolo
Development Editor: Lisa Bishop
Technical Editor: Jason Boche
Production Editor: Eric Charbonneau
Copy Editor: Tiffany Taylor
Editorial Manager: Pete Gaughan
Production Manager: Tim Tate
Vice President and Executive Group Publisher: Richard Swadley
Vice President and Publisher: Neil Edde
Book Designers: Maureen Forys and Judy Fung
Proofreader: Nancy Bell
Indexer: Ted Laux
Project Coordinator, Cover: Katherine Crocker
Cover Designer: Ryan Sneed
Cover Image: © Konstantin Inozemtsev/iStockphoto
Copyright © 2013 by John Wiley & Sons, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 978-1-118-40791-2
ISBN: 978-1-118-53823-4 (ebk.)
ISBN: 978-1-118-49394-6 (ebk.)
ISBN: 978-1-118-53819-7 (ebk.)
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (877) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Control Number: 2012951520
TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. VMware vSphere is a registered trademark of VMware, Inc. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
Publisher's Note
Dear Reader,
Thank you for choosing VMware vSphere Design, Second Edition. This book is part of a family of premium-quality Sybex books, all of which are written by outstanding authors who combine practical experience with a gift for teaching.
Sybex was founded in 1976. More than 30 years later, we're still committed to producing consistently exceptional books. With each of our titles, we're working hard to set a new standard for the industry. From the paper we print on to the authors we work with, our goal is to bring you the best books available.
I hope you see all that reflected in these pages. I'd be very interested to hear your comments and get your feedback on how we're doing. Feel free to let me know what you think about this or any other Sybex book by sending me an email at [email protected]. If you think you've found a technical error in this book, please visit http://sybex.custhelp.com. Customer feedback is critical to our efforts at Sybex.
To my beautiful wife Tarn. You are my blessing, my inspiration, my happiness, my courage, my pride, my today, and my tomorrow. Ever yours.
—Forbes Guthrie
First and foremost, I dedicate this work to my Lord and Savior, who goes with me and will never forsake me (Deuteronomy 31:6, NIV). I also dedicate this book to my family—Crystal, Sean, Cameron, and Tim. Thank you for your love and your support; it means the world to me.
—Scott Lowe
A dedication to my family: To my parents, Ron and Carol, for instilling a strong work ethic and sense of family, and supporting my education throughout the years. I wouldn't be where I am today without you. And to my wife Lauren, who has exemplified the virtue of patience and continues to be the most loving and supporting person I know. I love you hunny bunny.
—Kendrick Coleman
Acknowledgments
When accepting the challenge to revise this book from our previous incarnation, I certainly underestimated the voluminous nature of vSphere 5 and the multitude of new and improved features. Indubitable credit is due to VMware for delivering such progress. But that's not the point I'm trying to make. I've spent many evenings and weekends laboring over this task. Second time around, it has only been possible to devote so much time to it with the help and support of my wife, Tarn. Without her encouragement, this book would never have had my initial contributions and never been updated this year. Her mateship continues unbounded, and I'm forever grateful for the partnership we have. I would never have gotten through it once more. Thank you. Again.
I would like to acknowledge the book's other primary coauthor, Scott Lowe. He has stepped up to the plate with this edition, and his deep knowledge, experience, and style has enhanced the book considerably. Kendrick Coleman has been a fantastic addition to the team. He worked hard to provide wonderful insight into his disparate design topic, in an area that now complements the rest of the book so well. Thanks!
I continue to be amazed at the number of publishing-house staff involved in a single project. First and foremost I would like to thank Mariann Barsolo, the acquisitions editor, for her project steerage and the encouragement she gave to all the authors. We were all incredibly blessed to have Jason Boche (the Virtualization Evangelist) as our technical editor once more to check the subject matter and make suggestions so that every area was covered appropriately and was technically correct.
I grew up and was educated in Scotland, and I've lived and worked across the UK and in several English-speaking nations including New Zealand, Australia, and subsequently Canada. My interpretation of country-specific English lexicon, mixed with unique colloquialisms, makes for a frankly weird concoction of vernacular English. The Sybex editors' ability to decipher and translate this into something representing a sane American English dialect was undoubtedly no easy task. (However, I still maintain that the Queen's English is the only true authority, and virtualization should really be spelt with an s.) Lisa Bishop as the development editor probably bore the brunt of this and was always central to the smooth passage of the editing process. The Sybex team of Pete Gaughan, Connor O'Brien, and Jenni Housh kept a close guard on standards and made sure things were ticking along. The production team, headed up by Eric Charbonneau as the production editor, with Tiffany Taylor as the copy editor tidying the grammar into something respectable. Proofreader Nancy Bell's rapier-like eye for detail helped spot all the little mistakes that the rest of us managed to miss along the way, and Ted Laux had the unenviable but crucial task of indexing the text—thanks, guys.
From a technical perspective, the vast collection of resources from the VMware community, the bloggers, the book writers, the podcasters, the VMworld presenters, the instructors, and the forum members all helped immensely. My knowledge and understanding of the vSphere product line is directly attributable to all of you. There are unfortunately too many people who deserve rich thanks, but for fear of this turning into an Oscar speech, I can only say a huge thank you. You all know who you are. Here is a big virtual pat on the back from me.
Finally, I'd like to thank the wonderful baristas of South Granville and Fairview in Vancouver for their delicious highly caffeinated beverages and working refuge. Caffè Artigiano, Waves Coffee House, and in particular Starbucks have provided decidedly agreeable cups of joe to fuel me this time around.
—Forbes Guthrie
As with any book, many people deserve credit for the book you're now reading. First and foremost, I'd like to thank Forbes for the opportunity to collaborate on this revised edition. Forbes's outstanding work and unwavering commitment to getting this book done (and done in the highest possible quality) is a testament to his character, and I sincerely appreciate the chance to work with him once again. We've collaborated a couple of times: first for the original VMware vSphere Design, and again when he was a contributing author for Mastering VMware vSphere 5. In all instances, his work has been exemplary. Thanks for everything, Forbes—it has been a blast working with you once again.
My thanks also go to Kendrick Coleman, who was willing to jump in and contribute his technical expertise. The addition of his vCloud Director material helps fill an important gap in providing design guidance for an important part of many vSphere environments, and I appreciate his participation in this project.
Of course, there are so many people who need to be called out that it would be impossible to list all of them. I'd like to echo Forbes in saying thanks to all the great bloggers and other VMware community participants for their selfless contributions. It is fantastic to have such a great community from which to draw support and encouragement.
I'd also like to thank the team at Sybex: Mariann Barsolo, Pete Gaughan, Lisa Bishop, Eric Charbonneau, Tiffany Taylor, Nancy Bell, Ted Laux, Neil Edde, and the rest of the Sybex/Wiley team who worked so hard to bring this book to print. As with the previous books I've done with Sybex, it's been a pleasure, and I'm looking forward to more books in the future.
My thanks once again go to our technical editor, Jason Boche, for his efforts on this book. Jason, thank you for your honest feedback; I do believe this book is better as a result of your input.
My thanks also go to my Chinese exchange student, Tim, for bringing so much humor and laughter into our house during the writing of this book.
Last, but most certainly not least, I'd like to thank my family for putting up with me as I raced to meet deadlines while trying to balance work and home life. There is no doubt that without the support of my wife and my family, I would not have been able to complete this project. It's for you that I work so hard—thank you for your support.
—Scott Lowe
I've been approached many times to help author a publication, but I have always turned down the chance for one reason or another. When I was offered the opportunity to publish a chapter alongside Forbes and Scott, there was no way I could ever turn it down. Many thanks to Forbes and Scott for allowing me to tag along and publish a chapter in one of the best technical books ever to hit the shelf. It's an honor to share the stage with these gentlemen.
The VMware community at large also deserves a great deal of gratitude for everything you read in this book. One person can't be held responsible for dictating best practices; we rely on a community to decide. Many bloggers deserve credit for the knowledge they've shared and that has been transferred to this book. Without your real-world experience in the field, we wouldn't have the vast amount of information that's available to us all. You all rock.
Thank you to the Sybex/Wiley team for giving me this opportunity. I'm very grateful and appreciate all the work that goes on behind the scenes that makes publications such as this a success.
—Kendrick Coleman
About the Authors
Forbes Guthrie is an infrastructure architect who specializes in virtualization. He has worked in a variety of technical roles for over 14 years and achieved several industry certifications including VMware Certified Professional–Datacenter Virtualization (VCP2/3/4/5-DV) and VMware Certified Advanced Professional 5–Datacenter Design (VCAP5-DCD). His experience spans many different industries, and he has worked in Europe, Asia-Pacific, and North America. He holds a bachelor's degree in mathematics and business analysis and is a former Captain in the British Army.
Forbes was the lead author of this title's venerable first edition, co-authored by Scott Lowe and Maish Saidel-Keesing. He contributed to Scott's acclaimed Mastering VMware vSphere 5 book. Forbes has also spoken at VMware's own VMworld conference on the subject of design and vSphere 5.
Forbes' blog, www.vReference.com, is well regarded in the virtualization field and is aggregated on VMware's Planet V12n website. He is probably best known for his collection of free reference cards, long revered by those studying for their VMware qualifications. Forbes has been awarded the luminary designation of vExpert by VMware for his contribution to the virtualization community for the last three years in a row. His passion and knowledge have also been rewarded with the peer-reviewed top virtualization bloggers listing for the last four years running.
Scott Lowe is an author, a blogger, and a consultant focusing on virtualization, networking, storage, and other enterprise technologies. Scott is currently a technical architect at VMware, focusing on virtual networking; previously he worked as a technologist at EMC Corporation.
Scott's technical expertise extends into several areas. He holds industry certifications from Cisco, EMC, Microsoft, NetApp, and others. He's also one of the few people who have achieved the status of VMware Certified Design Expert (VCDX); Scott is VCDX #39. For his leadership and contributions in support of the VMware community, Scott is a four-time VMware vExpert award recipient (2009, 2010, 2011, and 2012).
Scott has published numerous articles on virtualization and VMware with a number of different online magazines, and he has been a featured speaker at numerous virtualization conferences as well as VMworld. Scott has spoken at four consecutive VMworld conferences (2009, 2010, 2011, and 2012). In addition to contributing to the first edition of this book, he has three other published books: Mastering VMware vSphere 4, VMware vSphere 4 Administration Instant Reference (with Jase McCarty and Matthew Johnson), and the best-selling Mastering VMware vSphere 5, all by Sybex.
Scott is perhaps best known for his acclaimed blog at http://blog.scottlowe.org, where he regularly posts technical articles on a wide variety of topics. Scott's weblog is one of the oldest virtualization-centric weblogs that is still active; he's been blogging since early 2005.
Scott lives in the Denver, Colorado, area with his wife Crystal, his two youngest sons (Sean and Cameron), and his Chinese exchange student (Tim).
Kendrick Coleman is an infrastructure architect focused on enterprise datacenter technologies. In his daily role, he is responsible for being a design and integration expert on many VMware products. Kendrick holds the following VMware certifications: VCP3/4/5-DV, VCAP4/5-DCD, VMware Certified Advanced Professional 4–Datacenter Administration (VCAP4-DCA), and VCP5-Cloud as well as being a Cisco Certified Network Associate (CCNA). Kendrick has also been recognized as a VMware vExpert (2010, 2011, and 2012) for his contributions to the VMware community.
Kendrick's blog, www.kendrickcoleman.com, is known for having various articles focused on vSphere network design, free VMware tools, step-by-step tutorials, and vCloud Director. Year after year, it's ranked as an influential virtualization blog. Kendrick has spoken at three consecutive VMworld conferences (2010, 2011, and 2012) and continues to travel the country to speak at VMUGs and other trade shows.
Introduction
This book has always stood out as a particularly interesting project for us. A multitude of vSphere textbooks are available, explaining every facet of configuring ESXi and vCenter. If you want to know how to do something in vSphere, you're literally spoiled for choice. However, in our minds, few resources properly encompass the design process. They exist for very specific features; but not many cover the entire design of a vSphere implementation in sufficient depth.
This revised, updated, and largely rewritten second edition of VMware vSphere Design has been thoroughly overhauled to encompass all the great new changes that have been introduced in vSphere up to and including version 5.1. We've been blown away by the sheer volume of improvements and additions to this product. Every area of vSphere design has been affected deeply, and the revamped book reflects this.
vSphere is the leading industry standard for hypervisors. It's simply the best enterprise solution available today. It has become this popular largely because of its wide range of features, efficiency, and flexibility. But for it to perform effectively in your datacenter, you must have a suitable architecture in place. This book is written to help you achieve that.
In addition to the changing landscape of vSphere in the datacenter, the book now incorporates another key tenet of VMware's datacenter portfolio: vCloud Director, its private/public cloud integration piece. This emerging technology is now deeply intertwined in the future of vSphere and becoming an essential skill for anyone currently involved or interested in vSphere design.
Above all, this is a technical book about a very complex subject. It's not concerned with the minutiae of every command-line tool, but rather with the underlying concepts. As vSphere has evolved from the early ESX days, it has grown in size to the point that every detail can't be covered in a single tome. But we sincerely believe this book fulfills its intended purpose better than anything else available. We'll dive into some areas not traditionally covered in such depth.
To that end, this book isn't a how-to manual with endless bullet-point instructions, but one that aims to make you think a little. It's for those of us who plan, design, implement, and optimize vSphere solutions. We hope it will challenge some of your preconceptions regarding the norm or what you consider best practice. Just because you designed a particular configuration one way in the past, doesn't mean it's a best fit for the next rollout. Here we try to question that prescriptive bias. Usually, that choice exists because different situations call for different answers. If there was one best solution for every case, then frankly no one would consider it a design choice at all.
This book isn't just for consultants who week by week deliver architectural solutions (although we hope you guys are here for the ride, too); it's for anyone who runs vSphere in their environment. It should make you question why things are set up the way they are, and encourage you to examine how to improve your environment even further.
There are constant advances in hardware, and vSphere is an ever-evolving tool, so it's always worth considering your existing deployments. Even if the hardware and software remain static in your environment, you can bet that new VMs will continue to appear. Nothing stands still for long, so your design should also be constantly growing to embrace those changes.
Each design decision has its own impact, and often these have a domino effect on many other elements. vSphere involves many disparate skills, such as guest OSes, server hardware, storage, and networking; and that's before you begin to consider the actual hypervisor. One of the hardest parts of a creating a viable design is that normally, no individual choice can be made in isolation. Although this book is naturally split into chapters, sections, and subsections, it's only when the design is considered as a complete solution that it can truly succeed.
The book employs several techniques to understand how you can approach design: the critical requirements and constraints; the impacts, benefits, and drawbacks of each choice; the dependencies on and relationships between each decision; and ultimately how to decipher what is best for you.
Who Should Read This Book
This book focuses on the design aspects of vSphere. It isn't primarily intended to teach you how to complete certain vSphere tasks, but rather to make you think about the why behind your different architectural decisions. We expect this book will be most useful for the following readers:
Infrastructure architects designing new vSphere environments
Engineers and architects charged with maintaining existing vSphere deployments, who wish to further optimize their setup
Anyone who appreciates the basics of vSphere but wants to learn more by understanding in depth why things are the way they are
Long-time experts who are always searching for that extra nugget of hidden information
Ways to Read the Book
There are several ways to approach this book. Clearly, you can read it from cover to cover, and we certainly encourage anyone wanting the fullest understanding of vSphere design to do so. Alternatively, if you need to brush up your knowledge on one key area, you can read each chapter in isolation. Or, if you need a specific answer to a key design decision, you should be able to jump in and use this as a reference book. VMware vSphere Design has been written so each section stands on its own, if that is all you need from it, but it should also be a jolly good read if you want to sit down and immerse yourself.
Other Resources Available
We're often asked for good sources of vSphere information, for those seeking absolute knowledge. Fortunately, there is a plethora of good places to look. The first stop for anyone (beyond this book, obviously) is VMware's own library of technical product documentation, which you can find at www.vmware.com/support/pubs. Along with the standard PDFs, the site also offers a wide variety of whitepapers, best practices, case studies, and knowledge-based articles.
Sybex has a number of excellent vSphere-focused books, such as Mastering VMware vSphere 5, a VCP5 Study Guide, a vSphere PowerCLI reference, and the vSphere 5 Administration Instant Reference, among others. A strong community of VMware users share knowledge through a number of different channels. The VMware forums at http://communities.vmware.com/community/vmtn are an excellent source of information and support for specific queries. There are a good number of vSphere-oriented blogs, the best of which tend to be aggregated on the popular Planet V12n site at www.vmware.com/vmtn/planet/v12n. Finally, if you want something a little closer to home, user groups are available in many places (see http://vmware.com/vmug), where you have the chance to meet other VMware users face to face to discuss and learn more about vSphere.
What You Need
To get started with VMware vSphere Design, you should have a basic understanding of virtualization, vSphere itself, and the associated VMware products. Both networking and storage concepts are discussed, because they're integral to any vSphere architecture, so a basic knowledge of them is assumed. The more hands-on experience you have with vSphere, the more you're likely to get out of this book. However, you don't need to be an expert beforehand.
No specific hardware or software is required while following this book, as long as you've seen the product before. But a lab is always useful to test some of many concepts we discuss. A simple nested VM lab run on a single platform should be sufficient to practice and explore most of the book's content.
What's Inside
Here is a glance at each chapter:
Chapter 1: An Introduction to Designing vSphere Environments
We begin by introducing you to the design process for vSphere delivery. This chapter explains how to understand the basic requirements and how to assess and then design a successful, valid implementation.
Chapter 2: The ESXi Hypervisor
This chapter explains the fundamental design choices around vSphere's ESXi hypervisor. The chapter looks into the architecture behind ESXi and examines the methods and considerations when deploying it across different organizations. We also provide design advice for its subsequent configuration and management.
Chapter 3: The Management Layer
In this chapter, we look at many of the software management pieces and how best to use them in different design configurations.
Chapter 4: Server Hardware
This chapter provides an in-depth examination of the components that make up a server and how each one affects the performance of vSphere. You need to consider many factors when selecting server hardware, and we look at them, including scaling-up versus scaling-out approaches. We also debate the merits of blade and rack servers.
Chapter 5: Designing Your Network
This chapter covers the complex decisions you need to make to ensure that network traffic provides sufficient throughput, redundancy, and security. We look how different vSphere components can affect those designs, and we provide some example configurations.
Chapter 6: Storage
In this chapter, we analyze the different factors that influence a complete virtualization storage strategy, comparing availability, performance, and capacity. We contrast different storage protocols and explain how to configure multipathing in different setups. Finally, we examine vSphere 5's new storage features and how they can enhance your design.
Chapter 7: Virtual Machines
In this chapter, we describe each VM component in turn, to help you understand how VMs should be designed to make the most efficient solution for you. We look at how to optimize the OS and the applications within VMs and then explain different methods of efficiently replicating the VM design though the use of clones and templates. Additionally, we look at some techniques to protect those VMs with clustering solutions, and how Infrastructure Navigator can identify the interrelationships between VMs.
Chapter 8: Datacenter Design
This chapter examines in detail each element of a vSphere inventory's hierarchy. It looks at the importance of clusters in the design and how to successfully implement the resource-management and redundancy features of a cluster. We discuss resource pools, DRS, DPM, the new version of HA, and FT, and what interdependencies exist when they're used in combination.
Chapter 9: Designing with Security in Mind
Chapter 9 highlights some of the areas that security-conscious environments can use to ensure that vSphere is suitably strengthened. It explains the different security measures included in the hypervisor, examines the management tools, and discusses how best to tighten that security as required.
Chapter 10: Monitoring and Capacity Planning
This chapter explains the concepts of monitoring and capacity planning. Monitoring relates to the present or recent past, whereas capacity planning looks to the future. The chapter also examines some of the common tools used for both and how to involve them in your design.
Chapter 11: Bringing a vSphere Design Together
In this chapter, we return to the overall design strategy by looking at a specific example through a design for a fictitious company. We discuss several of the decisions made during the design, examine the justifications behind those decisions, and consider alternative choices that could have been made.
Chapter 12: vCloud Design
This chapter highlights the topics involved in architecting a successful vCloud Director implementation. We examine the role vCloud Director plays in a cloud infrastructure and dive into designing individual vCloud Director components, such as Provider vDCs and Organization vDCs.
How to Contact the Authors
We welcome feedback from you about this book or about books you'd like to see from us in the future. You can reach Forbes Guthrie by writing to [email protected], on Twitter at @forbesguthrie, or by visiting his blog at www.vReference.com. You can reach Scott Lowe at [email protected], on Twitter at @Scott_Lowe, or by visiting his blog at http://blog.scottlowe.org. You can reach Kendrick Coleman at [email protected], on Twitter at @KendrickColeman, or by visiting his website, www.kendrickcoleman.com.
Sybex strives to keep you supplied with the latest tools and information you need for your work. Please check the book's website at www.sybex.com/go/vspheredesign2e, where we'll post additional content and updates that supplement this book should the need arise.
Chapter 1An Introduction to Designing VMware Environments
Designing VMware vSphere environments can be a complex topic, one that means many different things to many different people. In this chapter, we'll provide an introduction to designing VMware vSphere implementations. This introduction will give a preview of some of the more detailed discussions that take place in later chapters and will provide a framework for how the other chapters fit into the overall process.
This chapter will cover the following topics:
The importance of functional requirements in VMware vSphere design
The what, who, and how questions involved in VMware vSphere design and why they're important
An overview of the VMware vSphere design process
What Is Design?
When we talk about “designing your VMware vSphere environment,” what exactly does that mean? In the context of VMware vSphere, what is design? What does design entail? These are excellent questions — questions that we intend to answer in this chapter and the coming chapters throughout this book.
In our definition, design is the process of determining the way in which the different elements that make up a VMware vSphere environment should be assembled and configured to create a virtual infrastructure that is strong yet flexible. Design also includes the process of determining how this virtual infrastructure will integrate with existing infrastructure as well as how the virtual infrastructure will be operated after the implementation is complete.
That's a reasonable definition; but for someone who is new to VMware vSphere design, does this really describe what design is? Does it help you understand the nature of design, or what makes up a design?
In looking at a VMware vSphere design, we can say that it has three key facets: the technical or structural facet, the organizational facet, and the operational facet. Figure 1.1 shows how these three facets are all part of the larger entity that we refer to as design.
These three facets serve to organize the design in a way that is logical to us, grouping together information, decisions, criteria, constraints, and standards. We'll explore these facets in more detail later in this chapter in the section titled “The Facets of vSphere Design.”
Figure 1.1 The different parts of VMware vSphere design are merely facets of a larger entity.
When defined or described this way, VMware vSphere design seems simple. But as you'll see in this book — or perhaps as you've already seen, depending on your experience — it can be complex. Even in the most complex of designs, however, a single unifying element brings the different facets together. What is this single unifying element, as illustrated in Figure 1.2? It's the functional requirements of the design.
Figure 1.2 The functional requirements unify the different facets of the design.
Functional requirements are incredibly important. In fact, we can't stress enough the key role that functional requirements play in VMware vSphere design (or any IT design task, for that matter). Functional requirements are important because they answer the question “What things should this design do?”
It's important to remember that companies implement VMware vSphere for a reason, not just for the sake of having vSphere installed. As much as VMware would love for that to be the case, it's not. In every instance, there's a driving factor, a force, a purpose behind the implementation. There's a reason the company or organization is implementing VMware vSphere. That reason, naturally, varies from customer to customer and organization to organization.
Here are some example reasons taken from our own experience in the virtualization industry:
Consolidation
The company or organization has too many physical servers and needs to reduce that number. The need to reduce the number of physical servers can be driven by any number of reasons, including a need to reduce data-center space usage, a need to cut power and cooling costs, or an attempt to reduce hardware refresh costs.
New Application Rollout
The company or organization is deploying a new application or a new service in its data center, and it has chosen to use virtualization as the vehicle to accomplish that deployment. This may be a deployment of a new version of an application; for example, a company currently using Exchange 2007 may decide to roll out Exchange 2010 in a virtualized environment on VMware vSphere. As another example, a company deploying SAP may choose to do so on VMware vSphere. The reasons for choosing to deploy on a virtualized environment are too numerous to list here, but they can include increased utilization, simplified deployment, and better support for a disaster recovery/business continuity (DR/BC) solution.
Disaster Recovery/Business Continuity (DR/BC)
The company or organization is in the midst of developing or enhancing its DR/BC solution and has chosen to use virtualization as a key component of that solution. Perhaps the company is using array-based replication and wishes to use VMware vSphere and VMware Site Recovery Manager (SRM) to provide a more automated DR/BC solution. The choice to use virtualization as a component of a DR/BC solution is almost always a financial one; the company or organization wishes to reduce the amount of downtime (thus minimizing losses due to downtime) or reduce the cost of implementing the solution.
Virtual Desktop Infrastructure
The company or organization wishes to deploy a virtual desktop infrastructure (VDI) in order to gain desktop mobility, a better remote-access solution, increased security, or reduced desktop-management costs. Whatever the motivation, the reason for the VMware vSphere environment is to support that VDI deployment.
As you can see, the reasons for adopting virtualization are as varied as the companies and organizations. There is no one reason a company will adopt virtualization, but there will be a reason. There are often multiple reasons. These reasons become the basis for the functional requirements of the design. The reasons are the things the design must do. Functional requirements formalize the reasons why the company or organization is adopting VMware vSphere and turn them into actionable items that you'll use to drive all the other decisions in the design.
Think about some of the examples we just provided. Does the organization plan to virtualize a new rollout of Microsoft Exchange Server 2010? If so, then the VMware vSphere design had better accommodate that functional requirement. The design must specifically accommodate Microsoft Exchange Server 2010 and its configuration needs, supportability requirements, and resource constraints. If you fail to properly account for the fact that Microsoft Exchange Server 2010 will run in this virtualized environment, then you've failed to consider one of the design's functional requirements — and, in all likelihood, the implementation will be a failure. The design will fail to do the thing the company needs it to do: run Microsoft Exchange Server 2010.
With this in mind, you can look back at Figure 1.2 and better understand how the functional requirements both surround and unify the facets of VMware vSphere design. Continuing in our example of an organization that is deploying Exchange Server 2010 in a virtualized environment, the functional requirements that derive from that reason affect a number of different areas:
The server hardware selected needs to be capable of running the virtual machines configured with enough resources to run Microsoft Exchange Server 2010.
The virtual machines that run Exchange will, most likely, need to be configured with more RAM, more virtual CPUs (vCPUs), and more available disk space.
The configuration of Exchange Server 2010 will affect cluster configurations like the use of vSphere High Availability (HA), vSphere Distributed Resource Scheduler (DRS), and vSphere Fault Tolerance (FT).
The cluster configuration, such as the ability (or inability) to use vSphere FT, will in turn affect the networking configuration of the VMware ESXi hosts in the environment.
Operational procedures need to be included in the design as a result of the use (or lack of use) of features like vSphere HA, vSphere DRS, and vSphere FT.
