VMware Architecting vCloud WP

100
VMware vCloud Architecting a vCloud Version 1.6 TECHNICAL WHITE PAPER

description

VMware Architecting vCloud

Transcript of VMware Architecting vCloud WP

  • VMware vCloud Architecting a vCloud Version 1.6

    T e c h n i c a l W h i T e P a P e R

  • VMware vCloudArchitecting a vCloud

    T e c h n i c a l W h i T e P a P e R / 2

    Table of contents

    List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

    List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

    1. What is a VMware vCloud? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    1.1 Document Purpose and Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

    1.2 Cloud Computing and vCloud Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

    1.3 vCloud Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

    1.4 vCloud Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

    1.4.1 vCloud Management Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    1.4.2 Compute Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

    1.4.3 Storage Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

    1.4.4 Networking Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

    1.4.5 Component Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

    1.4.6 vCloud Consumer Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

    1.4.7 vCloud Logical Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

    2. vCloud Director Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

    3. vCloud Consumer Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

    3.1 Cloud Consumer Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

    3.2 Establish Provider Virtual Datacenters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

    3.2.1 Public Cloud Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.2.2 Private Cloud Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

    3.2.3 Provider Virtual Datacenter Special Use Cases . . . . . . . . . . . . . . . . . . . . 18

    3.2.4 Compute Resources Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

    3.2.5 Storage Resources Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

    3.2.6 Networking Resources Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

    3.3 Multi-Site/Multi-Geo Clouds. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

    3.3.1 Scenario #1Common User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

    3.3.2 Scenario #2Common Set of Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

    3.3.3 Suggested Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22

    3.3.4 Other Multi-Site Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

    3.3.5 Merging Chargeback Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

    3.3.6 Synchronizing Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

  • VMware vCloudArchitecting a vCloud

    T e c h n i c a l W h i T e P a P e R / 3

    4. Providing Cloud Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

    4.1 Establish Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

    4.1.1 Administrative Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

    4.1.2 Standard Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

    4.2 Establish Networking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

    4.2.1 External Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

    4.2.2 Network Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

    4.2.3 Cisco Nexus 1000V Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

    4.3 Establish Networking OptionsPublic vCloud Example . . . . . . . . . . . . . . . . . . . .26

    4.3.1 External Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

    4.3.2 Network Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

    4.3.3 Organization Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

    4.3.4 Cisco Nexus 1000V Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

    4.4 Establish Networking OptionsPrivate vCloud Example . . . . . . . . . . . . . . . . . . . 30

    4.4.1 External Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

    4.4.2 Network Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

    4.4.3 Organization Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

    4.4.4 Cisco Nexus 1000V Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

    4.5 Establish Organization Virtual Datacenters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

    4.5.1 Public vCloud Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

    4.5.2 Private vCloud Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32

    4.6 Create vApp Templates and Media Catalogs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

    4.6.1 Auto-Joining Active Directory Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

    4.6.2 Establish Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

    4.6.3 Accessing your vCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    4.6.4 Deploy vApps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    4.6.5 Employ Chargeback or Showback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    5. Extending vCloud Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    5.1 Core vCloud Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    5.2 vCloud Request Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

    5.3 vCloud API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

    5.4 vCenter Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

    5.4.1 Cloud Administration Orchestration Examples . . . . . . . . . . . . . . . . . . . . . .37

    5.4.2 Organization Administration Orchestration Examples . . . . . . . . . . . . . . .37

    5.4.3 Cloud Consumer Operation Orchestration Examples . . . . . . . . . . . . . . . .37

  • VMware vCloudArchitecting a vCloud

    T e c h n i c a l W h i T e P a P e R / 4

    5.5 vCloud Connector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    5.5.1 vCloud Connector Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    5.5.2 vCloud Connector Example Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . .39

    5.5.3 vCloud Connector Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39

    6. Managing the vCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.1 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.1.1 Management Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.1.2 Cloud Consumer Resources and Workloads . . . . . . . . . . . . . . . . . . . . . . . 40

    6.2 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

    6.2.1 Logging Architectural Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

    6.2.2 Logging as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42

    6.3 End-to-End Security Considerations with vCloud . . . . . . . . . . . . . . . . . . . . . . . . . .43

    6.3.1 vCloud Environment Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

    6.3.2 User Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

    6.3.3 Securing Workloads at the NetworkLevel Workload Security . . . . . .43

    6.4 Workload Availability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

    6.4.1 Uptime SLAs at 99.99% . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

    6.4.2 Load Balancing of vCloud Director Cells . . . . . . . . . . . . . . . . . . . . . . . . . . .45

    6.4.3 I/O Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

    6.4.4 Disaster Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

    6.4.5 Backup and Restore of vApps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

    7. Sizing the vCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

    7.1 Initial Sizing of Cloud Consumer Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

    7.2 Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

    8. Implementing Your vCloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

    9. Appendix: vCloud Director Cell Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

    10. Appendix: vCloud Availability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

    11. Appendix: Security Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

    11.1 Network Access Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

    11.2 Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

    11.3 Use Cases: Why Logs Should be Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63

    11.3.1 Example Compliance Use Cases for Logs . . . . . . . . . . . . . . . . . . . . . . . . . 64

    11.3.2 VMware vCloud Log Sources for Compliance . . . . . . . . . . . . . . . . . . . . . . .65

    11.4 vCloud Director Diagnostic and Audit Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

    11.5 Load Balancer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

    12. Appendix: Signed Certificates with vCloud Director . . . . . . . . . . . . . . . . . . . . . . . . . . 70

  • VMware vCloudArchitecting a vCloud

    T e c h n i c a l W h i T e P a P e R / 5

    13. Appendix: Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

    13.1 Cloud Administrator (Service Provider) Perspective . . . . . . . . . . . . . . . . . . . . . . . .87

    13.2 Network Capacity Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92

    14. Appendix: Capacity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

    14.1 vCloud-Specific Capacity Forecasting (Demand Management) . . . . . . . . . . . . .93

    14.2 Capacity Monitoring and Establishing Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . .93

    14.3 Capacity Management Manual ProcessesProvider Virtual Datacenter . . . . . 94

    14.4 End-Customer (Organization) Administrator Perspective . . . . . . . . . . . . . . . . . . .95

    14.5 Organization Virtual DatacenterSpecific Capacity Forecasting . . . . . . . . . . . . 97

    14.6 Capacity Management Manual ProcessesOrganization Virtual Datacenter . . .100

  • VMware vCloudArchitecting a vCloud

    T e c h n i c a l W h i T e P a P e R / 6

    list of Figures

    Figure 1. vCloud Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

    Figure 2. Core vCloud Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

    Figure 3. vCloud Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

    Figure 4. vCloud Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

    Figure 5. vCloud Director Construct to vSphere Mapping . . . . . . . . . . . . . . . . . . . . . . . . 15

    Figure 6. vCloud Consumer Resource Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

    Figure 7. Two Sites with Local vCloud Director Instances Managing Local vCenters . 21

    Figure 8. Remote Console Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

    Figure 9. Two Sites with Isolated vCloud Director Instances . . . . . . . . . . . . . . . . . . . . . . . 23

    Figure 10. Example Diagram of Provider Networking for a Public vCloud . . . . . . . . . . 27

    Figure 11. Configure External IPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

    Figure 12. vCloud Director Logical Networking w/ Cisco Nexus 1000V . . . . . . . . . . . . 29

    Figure 13. Example Diagram of Provider Networking for a Private vCloud . . . . . . . . . . 30

    Figure 14. vCloud Connector Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

    Figure 15. Architectural Example Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

    Figure 16. Configure Firewall Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

    Figure 17. Reference Architecture Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

    Figure 18. Log Collection in the Cloud Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

    Figure 19. Architecture of vCloud Components and Log Collection . . . . . . . . . . . . . . . . 65

    Figure 20. Infrastructure Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

  • VMware vCloudArchitecting a vCloud

    T e c h n i c a l W h i T e P a P e R / 7

    list of Tables

    Table 1. Reference Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

    Table 2. vCloud Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

    Table 3. vCloud Director Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

    Table 4. Component Requirements for a Management Cluster . . . . . . . . . . . . . . . . . . . . 19

    Table 5. Network Pool Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

    Table 6. vCloud vApp Requirements Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

    Table 7. Definition of Resource Pool and Virtual Machine Split . . . . . . . . . . . . . . . . . . . . . 49

    Table 8. Memory, CPU, Storage, and Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

    Table 9. Example Consolidation Ratios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

    Table 10. MBeans Used To Monitor vCloud Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

    Table 11. vCloud Availability Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

    Table 12. Network Access Security Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

    Table 13. Audit Concerns Within The Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

    Table 14. vCloud Component Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

    Table 15. Other Component Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

    Table 16. Load Balancer Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

    Table 17. Certificate Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

    Table 18. vSphere Host Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

    Table 19. Determing Redundancy Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

    Table 20. Network Capacity Planning Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

    Table 21. Capacity Monitoring Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

    Table 22. Organization Virtual Datacenter Units of Consumption . . . . . . . . . . . . . . . . . . 95

    Table 23. Recommended Organization Virtual Datacenter Capacity Thresholds . . . . . 95

    Table 24. Sample Organization Virtual Datacenter Resource Allocation . . . . . . . . . . . . 96

    Table 25. Organization Virtual Datacenter Trending Information . . . . . . . . . . . . . . . . . . . .97

    Table 26. Organization Virtual Datacenter Capacity Trending Variables . . . . . . . . . . . . 98

    Table 27. Sample Organization Virtual Datacenter Trending Information . . . . . . . . . . . . 99

  • T e c h n i c a l W h i T e P a P e R / 8

    VMware vCloudArchitecting a vCloud

    1. What is a VMware vCloud?1.1 Document Purpose and AssumptionsArchitecting a vCloud is intended to serve as a reference for cloud architects. The target audience is VMware Certified Professionals (VCP) familiar with VMware products, particularly VMware vSphere (vCenter Server, ESXi, vShield Manager), VMware vCenter Chargeback, and VMware vCloud Director.

    Before proceeding with the rest of this document, you should have read the Service Definition for the type of cloud you are building, private or public. This document is not intended to be a substitute for detailed product documentation, nor is it a step-by-step guide for installing a vCloud. You should have access to the following documentation referred to throughout this document for step-by-step instructions on installing and configuring various components.

    TopiC RefeRenCed doCuMenT

    Cloud Requirements Requirements for a Cloud

    vCloud Service Definitions Service Definition for Public Cloud

    Service Definition for Private Cloud

    vCloud Implementations Service Provider Public vCloud Implementation Example

    Private vCloud Implementation Example

    vCloud Director vCloud Director Installation and Configuration Guide

    vCloud Director Administrators Guide

    vCloud Director Security Hardening Guide

    vCloud API vCloud API Specification

    vCloud API Programming Guide

    vSphere vSphere Datacenter Administration Guide

    vSphere Resource Management Guide

    vShield vShield Administration Guide

    vCenter Chargeback vCenter Chargeback Users Guide

    Using vCenter Chargeback with VMware Cloud Director Technical Note

    vCenter Orchestrator (vCO) vCenter Orchestrator Developers Guide

    VMware vCenter Orchestrator Administration Guide

    vCenter Server 4.1 Plug-In API Reference for vCenter Orchestrator

    vCloud Request Manager vCloud Request Manager Installation and Configuration Guide

    vCloud Request Manager Users Guide

    Table 1. Reference Documentation

  • T e c h n i c a l W h i T e P a P e R / 9

    VMware vCloudArchitecting a vCloud

    For further information, refer to the set of documentation for the appropriate product. For additional guidance and best practices, refer to the Knowledge Base on vmware.com.

    1.2 Cloud Computing and vCloud IntroductionA vCloud is VMwares cloud solution built on VMware technologies and solutions to deliver cloud computing. Cloud computing is a new approach to computing that leverages the efficient pooling of on-demand, self-managed virtual infrastructure to provide resources consumable as a service.

    Cloud computing can be delivered as three layers of service delivery:

    Infrastructure as a Service (IaaS)

    Platform as a Service (PaaS)

    Software as a Service (SaaS)

    This iteration of a vCloud focuses strictly on the IaaS layer.

    The vCloud will build upon VMware vSphere by extending the robust virtual infrastructure capabilities to facilitate delivery of infrastructure service via cloud computing.

    1.3 vCloud ComponentsThe VMware vCloud is comprised of the following components:

    vCloud Request Manager

    vCloud API

    vCloudConnector

    vCenterOrchestrator

    vCloudDirector

    VMware vSphere

    vShield Edge

    vCenter Chargeback

    Figure 1. vCloud Overview

  • T e c h n i c a l W h i T e P a P e R / 1 0

    VMware vCloudArchitecting a vCloud

    vCloud CoMponenT desCRipTion

    VMware vCloud Director (vCD)

    vCloud API

    Cloud Coordinator and UI. Abstracts vSphere resources.

    Includes:

    vCloudDirectorServer(s)(alsoknownascell)

    vCloudDirectorDatabase

    vCloudAPI,usedtomanagecloudobjects

    vCloud API API used to programmatically interact with a vCloud

    VMware vSphere Underlying foundation of virtualized resources.

    The vSphere family of products includes:

    vCenterServerandvCenterServerDatabase

    ESXihosts,clusteredbyvCenterServer

    ManagementAssistant

    VMware vShield Provides network security services

    Includes:

    vShieldManager(VSM)virtualappliance

    vShieldEdge*virtualappliances,automaticallydeployedbyvCloudDirector *ThefullylicensedversionofvShieldEdgeincludesoptionalfeaturessuchasVPNandloadbalancing that are not integrated with vCloud Director.

    VMware vCenter Chargeback Optional component that provides resource metering and reporting to facilitate resource showback/chargeback

    Includes:

    vCenterChargebackServer

    ChargebackDataCollector

    vCloudDataCollector

    VSMDataCollector

    VMware vCenter Orchestrator Optional component that facilitates orchestration at the vCloud API and vSphere levels.

    VMware vCloud Request Manager Optional component that provides provisioning request and approval workflows, software license tracking, and policy-based cloud partitioning.

    VMware vCloud Connector Optional component to facilitate transfer of a powered-off vApp in OVF format from a local vCloud or vSphere to a remote vCloud

    Table 2. vCloud Components

    Other VMware or third-party products or solutions are not addressed in this iteration of a vCloud.

  • T e c h n i c a l W h i T e P a P e R / 1 1

    VMware vCloudArchitecting a vCloud

    From an architectural view, the following diagram shows how the core vCloud components interrelate.

    VMVM

    VMVM

    VMVMVMware

    VMVM

    VMVM

    VMVMVMware

    VMVM

    VMVM

    VMVMVMware

    VMVM

    VMVM

    VMVMVMware

    VMVM

    VMVM

    VMVMVMware

    VMVM

    VMVM

    VMVMVMware

    VMware vSphere

    VMware vCloud Director (vCD)

    vShield

    vCenter Chargeback

    vCloud API

    vCloud Director Cell

    NFS Server

    End UsersvCloud DirectorWeb Console

    vCloud Director Database

    vCenterService LDAP

    vCenter DatabasevCenter ChargebackServer

    DataCollectors vCenter

    ChargebackDatabase

    vCenter ChargebackWeb Interface

    vSphere Client

    Datastores

    vCloudAgent

    vCloudAgent

    vCloudAgent

    vCloudAgent

    vCloudAgent

    vCloudAgent

    ESX/ESXiHosts

    vShield Manager and vShield Edge Virtual Appliances

    Figure 2. Core vCloud Logical Architecture

    1.4 vCloud InfrastructureFrom an infrastructure perspective, a vCloud is built on a foundation of virtual infrastructure, whose components are split between a management cluster and cloud consumer resources.

    ManagementCluster

    Virtual Infrastrucure

    Cloud Consumer Resources

    Compute Storage Networking

    Figure 3. vCloud Infrastructure

    In building a vCloud, we assume that all management components, such as vCenter Server and vCenter Chargeback Server, will run in virtual machines.

    As a best practice of separating resources allocated for management functions from pure user-requested workloads, the underlying vSphere clusters will be split into two logical groups:

    A single management cluster running all core components and services needed to run the cloud.

    RemainingavailablevCenterclustersareaggregatedintoapoolcalledcloudconsumerresources.Theseclusters will be under the control of VMware vCloud Director. Multiple clusters can be managed by the same vCenter Server or different vCenter Servers, but vCloud Director will be managing the clusters through the vCenter Servers.

  • T e c h n i c a l W h i T e P a P e R / 1 2

    VMware vCloudArchitecting a vCloud

    Reasons for organizing and separating vSphere resources include:

    Ensuring that management components are separate from the resources they are managing.

    Minimizing overhead for cloud consumer resources. Resources allocated for cloud use have little overhead reserved. For example, cloud resource groups would not host vCenter virtual machines.

    Dedicating resources for the cloud. Resources can be consistently and transparently managed and carved up, and scaled horizontally.

    ManagementCluster

    Virtual Infrastrucure

    Compute Storage Networking

    Cloud Consumer Resources

    The underlying vSphere Infrastructure will follow vSphere best practices. Design considerations specific to a vCloud will be addressed accordingly in this document, organized by the vCloud management cluster and cloud consumer resources.

    1.4.1 vCloud Management Cluster

    ManagementCluster Compute Storage Networking

    Virtual Infrastrucure

    Cloud Consumer Resources

    The management cluster will follow vSphere best practices to facilitate load balancing, redundancy, and high availability.

    1.4.2 Compute ResourcesCompute resources for the management cluster will follow vSphere best practices where possible, including but not limited to VMware DRS, HA, and FT.

    To facilitate VMware HA, a cluster of three VMware ESXi hosts will be used. While additional hosts can be added, threehostssupportingjustvCloudmanagementcomponentsshouldbesufficientfortypicalvCloudenvironments. Detailed sizing guidance of the management cluster is provided later in this document. Use a VMwareHApercentage-basedadmissioncontrolpolicyinanN+1fashioninsteadofdedicatingasinglehostfor host failures or defining the amount of host failures a cluster can tolerate. This will allow the management workloads to run evenly across the hosts in the cluster without the need to dedicate a host strictly for host failuresituations.AdditionalhostscanbeaddedtothemanagementclusterforN+2ormoreredundancybutthis is not required by the current vCloud Service Definitions.

    Use VMware HA (including VM Monitoring) and/or FT, where possible, to protect the management virtual machines. vCenter Site Recovery Manager (SRM) can be used to protect components of the management cluster. At this time, vCenter Site Recovery Manager will not be used to protect vCloud Director cells because a secondary (DR) site is out of scope of the vCloud, and changes to IP addresses and schemas in recovered vCloud Director cells can result in problems.

  • T e c h n i c a l W h i T e P a P e R / 1 3

    VMware vCloudArchitecting a vCloud

    Unlike a traditional vSphere environment where vCenter Server is used by administrators to provision virtual machines, vCenter Server plays an integral role in end-user self-service provisioning by handling all virtual machine deployment requests by vCloud Director. Therefore, VMware recommends that vCenter Servers are made available with a solution such as vCenter Heartbeat. Since FT is not supported for a multi-vCPU virtual machine, this is another reason for using vCenter Heartbeat for high resiliency.

    1.4.3 Storage ResourcesShared storage in the management cluster will be configured to include, but not limited to, the following:

    Storage paths will be redundant at the host (connector), switch, and storage array levels.

    All hosts in a cluster will have access to the same datastores.

    1.4.4 Networking ResourcesHost networking in the management cluster will be configured to include (but not limited to) the following:

    Logical separation of network traffic for security and load considerations by type (management, virtual machine, vMotion/FT, IP storage.

    Networkcomponentandpathredundancy.

    Atleast10GigEorGigEnetworkspeeds,ifavailable.

    UseofvNetworkdistributedswitcheswherepossiblefornetworkmanagementsimplification.ThearchitecturecallsfortheuseofvNetworkdistributedswitchesintheuserworkloadresourcegroup,soitisabestpracticetousethevNetworkDistributedSwitchacrossallofyourclusters,includingthemanagementcluster.

    IncreasingtheMTUsizeofthephysicalswitchesaswellasthevNetworkdistributedswitchestoatleast1524(defaultis1500)toaccommodatetheadditionalMACheaderinformationusedbyvCloudDirectorNetworkIsolationlinks.vCloudDirectorNetworkIsolationiscalledforbytheService Definition and the architecture foundlaterinthisdocument.ThisneedstobedoneonthetransportnetworkforvCloudDirectorNetworkIsolation. Failure to increase the MTU size could affect performance due to packet fragmentation affecting network throughput of virtual machines hosted on the vCloud infrastructure.

    1.4.5 Component PlacementManagement components running as virtual machines in the management cluster include the following:

    vCenter Server(s) and vCenter Database

    vCloud Director Cell(s) and vCloud Director Database

    vCenter Chargeback Server(s)

    vShield Manager (one per vCenter Server)

    Note: vShield Edge appliances are deployed automatically by vCloud Director through vShield Manager as needed and will reside in the vCloud consumer resource clusters, not in the management cluster. They will be placed in a system resource pool by vCloud Director and vCenter. For additional information on the vShield Edge appliance and its functions, refer to the vShield Manager Administrator guides.

    Optional management functions, deployed as virtual machines include:

    vCenter Update Manager

    vCenter Capacity IQ

    VMware Management Assistant

    vCenter Orchestrator (part of vCenter Server)

    vCloud Request Manager and associated database

    The optional management virtual machines are not required by the Service Definition but they are highly recommended to increase the operational efficiency of the solution.

    Database components, if running on the same platform, can be placed on the same database server. For example, the databases used by vCloud Director, vCenter Chargeback, and vCloud Request Manager can be consolidated on the same database server.

  • T e c h n i c a l W h i T e P a P e R / 1 4

    VMware vCloudArchitecting a vCloud

    For more information on the resources needed by the virtual machines in the management cluster refer to the Sizing section later in this document.

    1.4.6 vCloud Consumer Resources

    ManagementCluster Compute Storage Networking

    Virtual Infrastrucure

    Cloud Consumer Resources

    The cloud consumer resources represent vCenter clusters to host cloud workloads. These resources will be carved up by vCloud Director. Well cover vCloud Director cloud constructs and definitions in the next section first before drilling down on the compute, storage, and networking resources.

    1.4.7 vCloud Logical InfrastructureIn summary, the vCloud logical architecture with vSphere resource separation is depicted as follows.

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    VMVM

    VM

    VMware

    VMVM

    VM

    Management Cluster vCloud Consumer Resources

    vCloud infrastructure virtual machine

    vCenter Servers & vCenter Database

    vCloud Director Cells & vCloud Director Database

    vCenter Chargeback Servers

    vShield Manager (1 per vCenter Server)

    Optional Management Functions, deployed as virtual machines

    vCenter Update Manager

    vCenter Capacity IQ

    VMware Management Assistant

    vCenter Orchestrator (part of vCenterServer)

    vCloud Request Manager

    No user workloads

    Space allocated to user workloads

    vCloud infrastructure virtual machines (small footprint)

    vShield Edge virtual appliances

    Figure 4. vCloud Logical Architecture

    The management cluster may also include virtual machines or have access to servers that provide infrastructure servicessuchasdirectory(LDAP/AD),timekeeping(NTP),networking(DNS,DHCP),andsecurity(certificate).Detailed considerations for sizing are addressed in the Sizing section.

  • T e c h n i c a l W h i T e P a P e R / 1 5

    VMware vCloudArchitecting a vCloud

    The management cluster resides in a single physical site. vCloud consumer resources also reside within the same physical site, ensuring a consistent level of service. Otherwise, latency issues might arise if workloads need to be movedfromonesitetoanother,overaslowerorlessreliablenetwork.Fordefinitionpurposes,thiscloudisdefined under the context of a single physical site, and does not span multiple sites.

    Considerations for connecting clouds representing different sites are addressed later in this document. Secondary DR sites are discussed later in the Disaster Recovery section of this document.

    2. vCloud director ConstructsVMware vCloud Director introduces logical constructs, such as virtual datacenters, and security boundaries, such as organizations, to facilitate multi-tenancy consumption of resources.

    The following diagram depicts the logical constructs within vCloud Director that abstract underlying vSphere resources.

    Organization A Organization B

    Users

    vApp Network

    Datastores

    Resource PoolsHost Cluster

    Port Groups ordvPort Groups

    vSphere

    External NetworksOrganization Network

    Organization vDCs

    Provider vDC: Gold

    Organization vDCs

    Provider vDC: Silver

    Organization vDC

    Provider vDC: Bronze

    Organization Network

    User CloudsUser Clouds

    Organization vDCs Organization vDCs

    vApp(VMs with vApp Network)

    vApp(VMs with vApp Network)

    Access Control

    Catalogs Provisioning Policies

    Users Access Control

    Catalogs Provisioning Policies

    Figure 5. vCloud Director Construct to vSphere Mapping

    vCloud diReCToR ConsTRuCT desCRipTion

    Provider Virtual Datacenter Logical grouping of vSphere compute resources (attached vSphere cluster and one or more datastores) for the purposes of providing cloud resources to consumers.

    Organization A unit of administration that represents a logical collection of users, groups, and computing resources, and also serves as a security boundary from which only users of a particular organization can deploy workloads and have visibility into such workloads in the cloud.

    In the simplest term, an organization = an association of related end consumers.

  • T e c h n i c a l W h i T e P a P e R / 1 6

    VMware vCloudArchitecting a vCloud

    vCloud diReCToR ConsTRuCT desCRipTion

    Organization Virtual Datacenter Subset allocation of a provider virtual datacenters resources assigned to an organization, backed by a vCenter resource pool automatically created by vCloud Director. An organization virtual datacenter allocates resources using one of three models:

    Payasyougo

    Reservation

    Allocation

    vApp Templates and Media Catalogs A collection of available services for consumption. Catalogs contain vApp templates (preconfigured containers of one or more virtual machines) and/or media (ISO images of operating systems).

    ExternalNetwork A network that connects to the outside using an existing vSphere network port group.

    OrganizationNetwork A network visible within an organization. It can be an external organization network with connectivity to an external network, and use a direct or routed connection, or it can be an internal network visible only to vApps within the organization.

    vAppNetwork A network visible within a vApp. It can be connected to other vApp networks within an organization and use a direct or routed connection, or it can be an internal network visible only to virtual machines within the vApp.

    NetworkPool(notshownindiagram) A set of pre-allocated networks that vCloud Director can draw upon as needed to create private networks andNAT-routednetworks.

    Table 3. vCloud Director Constructs

    3. vCloud Consumer Resources3.1 Cloud Consumer Resources

    ManagementCluster Compute Storage Networking

    Virtual Infrastrucure

    Cloud Consumer Resources

    The cloud consumer resources are dedicated vCenter clusters that host cloud workloads. These resources are carved up by vCloud Director in the form of one or more provider virtual datacenters, which is a vCenter cluster, andoneormoreattacheddatastores.NetworkingfortheresourcegroupwillencompassvSpherenetworksvisible to the hosts in that cluster. Provider virtual datacenters are further carved up into organization virtual datacenters, which are backed by vCenter resource pools.

  • T e c h n i c a l W h i T e P a P e R / 1 7

    VMware vCloudArchitecting a vCloud

    vCloud Consumer Resource = +Host Cluster

    Datastore

    (Includes visible networking)

    =

    Provider Virtual Data Center

    Organization Virtual Data Center

    Resource Pool

    Figure 6. vCloud Consumer Resource Mapping

    3.2 Establish Provider Virtual DatacentersA provider virtual datacenter is a construct in vCloud Director that maps to a vSphere cluster or resource pool and one or more datastores. When creating a provider virtual datacenter, take the following rules and guidelines into consideration:

    At least one provider virtual datacenter is required for a vCloud.

    A provider virtual datacenter can map to one and only one cluster. Once a cluster is attached to a provider virtual datacenter, it is no longer available for attachment to another provider virtual datacenter.

    While it is possible to back a provider virtual datacenter with a resource pool instead of a cluster, the best practice is to use a cluster. If additional hosts are later added to the cluster, the backed provider virtual datacenter automatically grows as well. This is not the case if a resource pool is used. Also, since vCloud Director manages vSphere resources by proxy through a vCenter Server and automatically creates resource pools within vCenter as needed to instantiate organization virtual datacenters, using vCenter Server to create resource pools or nested pools can go against the efficient allocation of resources by vCloud Director. Multiple parent-level resource pools can also add unnecessary complexity and lead to unpredictable results or inefficient use of resources, if the reservations are not set appropriately.

    It is not possible to attach a second cluster to a provider virtual datacenter at this time. If additional compute capacity is required, add more hosts in the vCenter cluster on the vSphere end.

    One or more datastores can be attached to a provider virtual datacenter. A datastore can be assigned to multiple provider virtual datacenters. As a best practice in segmenting storage, datastores should not be shared by multiple provider virtual datacenters.

    Create multiple provider virtual datacenters to differentiate computing levels or performance characteristics of a service offering. Segment by capacity, availability, or performance type. An example of differentiating by availabilitywouldbeN+1foraBronzeprovidervirtualdatacentervs.N+2foraSilverprovidervirtualdatacenter.

    As the level of expected consumption increases for a given provider virtual datacenter, add additional hosts to the cluster from vCenter and attach more datastores.

    As the number of hosts in the cluster backing a provider virtual datacenter approaches the halfway mark of vSphere limits, consider implementing controls to preserve headroom. Do this well ahead of approaching the cluster limits. For example, do not allow additional tenants for this particular virtual datacenter and utilize the additional hosts to be added to address increased resource demand for the existing tenants.

    If the cluster backing a provider virtual datacenter has reached the maximum number of hosts per vSphere design guidelines, create a new provider virtual datacenter associated with a new cluster. A provider virtual datacenter cannot span multiple host clusters.

  • T e c h n i c a l W h i T e P a P e R / 1 8

    VMware vCloudArchitecting a vCloud

    Refer to the Service Definition for guidance on the size of vSphere clusters and datastores to attach when creating a provider virtual datacenter.

    Consider:

    Expected number of virtual machines

    Size of virtual machines (CPU, RAM, disk)

    3.2.1 Public Cloud ConsiderationsConsiderations for a public vCloud include creating multiple provider virtual datacenters based on tiers of service that will be provided.

    Since provider virtual datacenters only contain CPU, memory, and storage resources and those are common across all of the requirements in the Service Definition for Public Cloud, you should create one large provider virtualdatacenterattachedtoavSphereclusterthathassufficientcapacitytorun1,500virtualmachines.Youshouldalsoleaveoverheadtogrowtheclusterwithmoreresourcesuptothemaximumof32hosts,shouldorganizations need to grow in the future.

    If you determine that your hosts do not have sufficient capacity to run the maximum number of virtual machines called out by the Service Definition for Public Cloud, then you will need additional provider virtual datacenters.

    3.2.2 Private Cloud ConsiderationsGiventhataprovidervirtualdatacenterrepresentsavSpherecluster,itiscommonlyacceptedthatasingleprovider virtual datacenter be established. Since provider virtual datacenters only contain CPU, memory, and storage resources and those are common across all of the requirements in the Service Definition for Private Cloud, you should create one large provider virtual datacenter attached to a cluster that has sufficient capacity torun400virtualmachines.

    Refer to the Service Definition for Private Cloud for details on the service tier(s) called for. Should it be determined that existing host capacity cant meet the requirement, or theres a desire to segment capacity along the lines of equipment type (for example, CPU types in different provider virtual datacenters), then establish a providervirtualdatacenterforPay-As-You-Gousecasesandaseparateprovidervirtualdatacenterfortheresource-reserved use cases.

    3.2.3 Provider Virtual Datacenter Special Use CasesThereareinstanceswhereaprovidervirtualdatacentermustbeviewedasspecialpurposeinonewayoranother. Special use-case provider virtual datacenters are a great example of what makes cloud computing so flexible and powerful. The primary driver behind this need is to satisfy the license restrictions imposed by a specific software vendor that stipulates that all the processors that could run specific software must be licensed for it, regardless of whether or not they actually are running that software.

    In order to meet the EULA requirements of such a software vendor, you can establish a purpose-specific provider virtual datacenter, populated with enough sockets of processing power to meet the need but limited to no more than what is needed in order to keep licensing costs down.

    An example of this, in practice, is establishing an Oracle-only provider virtual datacenter. Since a provider virtual datacenter is backed by a cluster, you can name a cluster for a special purpose and publish it to any and all clouds that might need the service. You then maintain enough paid licenses to cover all the sockets in that cluster, and you are covered under the EULA, because the guests can only run on one of the sockets in that cluster/resource pool.

    There is some level of user education needed to verify that all Oracle instances are deployed to the special purpose virtual datacenter; that is, vCloud Director does not provide a way to prevent someone from incorrectly deploying virtual machines. So, the enforcement has to be manual, typically through organizational processes.

    In the following example, you could name the virtual datacenter with a descriptive name to deploy all Oracle instances, or insert instructions in the vApp name so that users deploy to the correct virtual datacenter:

    Oracle Database Use Only! PvDC

  • T e c h n i c a l W h i T e P a P e R / 1 9

    VMware vCloudArchitecting a vCloud

    3.2.4 Compute Resources Considerations

    ManagementCluster Compute Storage Networking

    Cloud Consumer Resources

    Virtual Infrastrucure

    All hosts in will be configured per vSphere best practices, similar to the management cluster. VMware HA will also be used to protect against host and virtual machine failures.

    Provider vDCs can be of different compute capacity sizes (number of hosts, number of cores, performance of hosts) to support differentiation of compute resources by capacity or performance for service level tiering purposes.

    Organization vDCs in turn should be created based on what services are planned.

    For a detailed look at how to size the vCloud, refer to the Sizing section later in this document.

    The following table lists out the requirements for each of the components that will run in the vCloud Director management cluster. For the number of virtual machines and organizations listed in the Service Definitions you will not need to worry about scaling too far beyond the provided numbers.

    iTeM vCpu MeMoRy sToRAge neTWoRking

    vCenter Server 2 8GB 20GB 100MB

    Oracle Database 4 16GB 100GB 1GigE

    vCloudDirectorx2(stats for each)

    2 4GB 10GB 1GigE

    vCenter Chargeback 2 8GB 30GB 1GigE

    vShield Manager 1 4GB 512MB 100MB

    TOTAL 11 40 GB 161 GB* 3 GigE*

    * Numbers rounded up or down will not impact overall sizing

    Table 4. Component Requirements for a Management Cluster

    For the table above, the Oracle Database will be shared between the vCenter Server, the vCloud Director cells, and the vCenter Chargeback Server. Different users and instances should be used for each database instance in-line with VMware best practices.

    Inadditiontothestoragerequirementsabove,aNFSvolumeisrequiredtobemountedandsharedbyeachvCloud Director cell to facilitate uploading of vApps from cloud consumers. The size for this volume will vary depending on how many concurrent uploads are in progress. Once an upload completes the vApp is moved to permanent storage on the datastores backing the catalogs for each organization and the data no longer resides ontheNFSvolume.TherecommendedstartingsizefortheNFStransfervolumeis250GB.Youshouldmonitorthis volume and increase the size should you experience more concurrent or larger uploads in your environment.

  • T e c h n i c a l W h i T e P a P e R / 2 0

    VMware vCloudArchitecting a vCloud

    3.2.5 Storage Resources Considerations

    ManagementCluster Storage Networking

    Virtual Infrastrucure

    Compute

    Cloud Consumer Resources

    Shared storage in the consumer resources will be configured per vSphere best practices, similar to the management cluster. Storage types supported by vSphere will be used. The use of RDMs in the vCloud infrastructure is currently not supported and should be avoided.

    Creation of datastores will need to take into consideration Service Definition requirements and workload use cases, which will affect the number and size of datastores to be created. vCloud Director will assign datastores for use through provider virtual datacenters, and only existing vSphere datastores can be assigned.

    Datastores attached to provider virtual datacenters will be used for vCloud workloads, known as vApps. vSphere best practices apply for datastore sizing in terms of number and size. Vary datastore size or shared storage characteristic if providing differentiated or tiered levels of service. Sizing considerations include:

    Datastore storage expectations:

    Size a datastore sufficiently to allow for placement of multiple vApps, avoiding creating small datastores that can house only one or two vApps. A few large datastores are preferred over many small datastores, especially since consumers are not allowed to choose which datastores to place their workload on when selecting a virtual datacenter with more than one datastore; vCloud Director will choose the datastore with the most free space available.

    What is the average vApp size x number of vApps x spare capacity? For example: Average virtual machine size*#virtualmachines*(1+%headroom)

    What is the average virtual machine disk size?

    How many virtual machines are in a vApp?

    How many virtual machines are to be expected?

    How much spare capacity do you want to allocate for room for growth (express in a percentage)?

    Will expected workloads be transient or static?

    Datastore performance characteristics:

    Will expected workloads be disk intensive?

    What are the performance characteristics of the associated cluster?

    Refer to the requirements in the Service Definition and size your datastores accordingly.

    Additionally,anNFSsharemustbesetupandmadevisibletoallhostsforusebyvCloudDirectorfortransferringfilesinavCloudDirectormulti-cellenvironment.NFSistherequiredprotocolforthetransfervolume. Refer to the vCloud Director Installation and Configuration Guide for more information on where to mount this volume.

    See the Workload Availability section for additional storage and storage I/O factors to take into account.

  • T e c h n i c a l W h i T e P a P e R / 2 1

    VMware vCloudArchitecting a vCloud

    3.2.6 Networking Resources Considerations

    ManagementCluster Networking

    Virtual Infrastrucure

    Compute Storage

    Cloud Consumer Resources

    Host networking for hosts within a provider vDC will be configured per vSphere best practices in the same mannerasthevCloudmanagementcluster.Inaddition,thenumberofvNetworkDistributedSwitchportsperhostshouldbeincreasedfromthedefaultvalueof128tothemaximumof4096.Increasingtheportswillallowfor vCloud Director to dynamically create port groups as necessary for the private organization networks created later in this document. Refer to the vSphere Administrator Guide for more information on increasing this value.

    Networkingattheproviderandorganizationvirtualdatacenterlevelisdetailedinthenextsectiononprovidingcloud resources.

    3.3 Multi-Site/Multi-Geo CloudsvCloud Director is neither designed nor supported for multi-site deployments in the currently shipping version of the product, due to potential issues with network latency and reliability. In an environment with multiple sites, each site should be a separate cloud that can be potentially interconnected, rather than having a single cloud that spans the sites.

    Multi-site can mean a lot of different things to different audiences. Some providers would like to have one user interface that encompasses all of their sites. Some providers dont mind having multiple interfaces but they would like the same services available in each location. These scenarios are discussed here.

    3.3.1 Scenario #1Common User InterfaceInourexampleforscenario1wehavetwophysicallocationswhereweareprovidingcloudserviceandwewantboth of them to be in the same vCloud Director interface. The user interface is provided from the vCloud Director cells, which can sit in either location or in both locations. One of the vCloud Director cells will serve as the proxy for a vCenter Server in one of the sites as illustrated below.

    VMVM

    VM

    VMware

    VMVM

    VM

    Site 1

    vCenter Server

    VMVM

    VM

    VMware

    VMVM

    VM

    Site 2

    vCenter Server

    vCloud DirectorvCD vCD vCD vCD vCD vCD

    Figure 7. Two Sites with Local vCloud Director Instances Managing Local vCenters

  • T e c h n i c a l W h i T e P a P e R / 2 2

    VMware vCloudArchitecting a vCloud

    The local vCenter servers will control resources local to each site. This is a very logical setup of the infrastructure until you look at some of the user flows.

    Ifweareauserthatiscomingintosite#1requestingremoteconsoleaccesstoavirtualmachineinsite#1wearenotguaranteedtohavealltrafficstayinsite#1.ThisisbecausewecannotcontrolwhichvCloudDirectorcellistheproxyforwhichvCenterServer.WecouldcomeintoavCloudDirectorcellinsite#1whichwouldthenhavetotalktotheproxyforvCenterserver#1insite#2.ThatvCloudDirectorcellwouldthentalkbacktothevCenterserverinsite#1thatwouldthenfinishsettinguptheremoteconsoleconnectiontothelocalESXihostwiththevirtualmachineinquestioninsite#1.TrafficatthattimewouldthenflowthroughthevCloudDirectorcellthatinitiatedtherequestinsite#1.Thisisallillustratedbelow.

    VMVM

    VM

    VMware

    VMVM

    VM

    Site 1

    vCenter Server

    VMVM

    VM

    VMware

    VMVM

    VM

    Site 2

    vCenter Server

    vCDvCD vCD vCD vCD vCD

    Figure 8. Remote Console Flow

    One of the problems with this setup is how do you control which vCloud Director cell a user gets terminated on, based on virtual machine and site specific data? Its next to impossible to continue to figure this out and provide that logic to a load balancer. Another problem with the scenario is we need to have a central Oracle database for allofthevCloudDirectorcellsfrombothsites.Thiscreatesevenmoretrafficonthelinkbetweenthe2sitessincethe message bus in vCloud Director uses the Oracle database for communication. Overall this solution is less than optimal and only suggested for cross-campus multi-site configurations where site-to-site communication will not overwhelm the network and where network availability is highly reliable.

    3.3.2 Scenario #2Common Set of ServicesA more pragmatic approach to multi-site setups is to have a single vCloud Director setup in each of the sites that is isolated from other sites. This solves the network cross-talk issue but it introduces even more problems of its own. For example, how do you provide a common set of services across the different sites? How do you keep organization names and rights as well as catalogs, networks, storage, and other information common across the different sites? Currently there is no mechanism to do this in the currently shipping vCloud Director product. Using other VMware technologies included in the vSphere suite of products you can synchronize cloud deployments using automation scripts and provide common sets of services across locations.

    In an enterprise, a private vCloud maps to a single site. Multiple vClouds can be connected using vCloud Connector for offline vApp migrations. A public vCloud can be connected to form a hybrid cloud.

    3.3.3 Suggested DeploymentMulti-site deployments are not officially supported by VMware at this time. However, if you are still going to create a multi-site deployment, then the recommended way to deploy multi-site solutions is to set up an isolated vCloud Director instance in each location. This isolated vCloud Director instance would include local vCloud

  • T e c h n i c a l W h i T e P a P e R / 2 3

    VMware vCloudArchitecting a vCloud

    Director cells, vCenter Servers, an Oracle database instance, a vCenter Chargeback instance, and local vSphere resources as illustrated in the picture below.

    VMVM

    VM

    VMware

    VMVM

    VM

    Site 1

    vCenter Server

    VMVM

    VM

    VMware

    VMVM

    VM

    Site 2

    vCenter Server

    vCD vCD vCD vCD vCD vCD

    Figure 9. Two Sites with Isolated vCloud Director Instances

    In order to keep the sites synchronized with organization and resource information, VMware encourages you to create a set of onboarding scripts and workflows. These workflows would be used anytime you need to create a new organization or a new resource for an organization and would drive that creation across all cloud sites. The VMware cloud services organization can assist you in the creation of these customer specific workflows based on templates the cloud practice already has. VMware cloud services has created these template workflows using the vCenter Orchestrator product that is included with vSphere. By using the workflows for administrative resource creation you can keep multiple clouds synchronized with organization resources.

    3.3.4 Other Multi-Site ConsiderationsWhen creating multi-site configurations, there are resources out of the control of the vCloud setup that require some thought. How do you set up networking between the sites? How do you handle IP addressing? It is for these physical resource decisions, varying between customers, that we have not provided specific guidance on in the reference architecture. Setting up these physical resources is also not included in the sample scripts previously mentioned.

    3.3.5 Merging Chargeback ReportsIn our reference multi-site setup we included multiple vCenter Chargeback instances. In order to provide one common bill or usage report to your cloud consumer you must aggregate all of the chargeback reports into one report. You can leverage the vCenter Chargeback API as well as vCenter Orchestrator to pull chargeback reports from each vCenter Chargeback server and consolidate them into one master report.

    3.3.6 Synchronizing CatalogsSynchronizing catalogs between sites is the most time consuming task. When setting up multiple cloud sites you should designate one site as the master site for template creation and have all other sites be replication peers. It is advisable to leverage native storage array replication to replicate the storage for the templates in each catalog. Array replication can provide several benefits for long distance data movement including data de-duplication and compression. Once the data is synchronized you can leverage the catalog synchronization workflows provided by VMwarevCloud API to import the replicated templates into the appropriate catalogs in VMware vCloud Director.

    Synchronizing templates added at remote sites is out of scope for this version of the reference architecture. This feature can be added selectively by engaging VMware Professional Services.

  • T e c h n i c a l W h i T e P a P e R / 2 4

    VMware vCloudArchitecting a vCloud

    4. providing Cloud Resources4.1 Establish OrganizationsA vCloud contains one or more organizations. Each organization represents a collection of end consumers, groups, and computing resources. Users authenticate at the organization level, using credentials established by an organization administrator locally within vCloud Director or LDAP. LDAP integration can be done at the cloud system level or per organization. Before you can configure LDAP on a per organization level, you must configure LDAP at the cloud system level. Set this up based on the cloud organizations requirements. Please see the vCloud Installation and Configuration Guide on how to set up the LDAP service with vCloud Director.

    Users in an organization consume resources by selecting vApps from a predefined catalog.

    Whencreatingorganizations,thenameoftheorganizationwillbeusedintheURLtoaccesstheGUIforthatorganization. As an example, ACME would be accessed at https:///cloud/org/ACME. You should take care to avoid special characters or spaces in the organization name since that will affect the URL in undesirable ways.

    You can use the system defaults for most of the other organization settings. The one exception is leases, quotas, and limits. There are no specific requirements called out by the Service Definition for leases, quotas, and limits. The provider should set these values to whatever works best in their cloud.

    4.1.1 Administrative OrganizationA vCloud requires at least one organization. As a best practice, the first organization to be created should be an administrative organization. This organization will own a master catalog of vApp templates that are published and shared with all other (standard) organizations.

    Administrators assigned to the administrative organization will also be responsible for creating official template virtual machines for placement in the master catalog for other organizations to use. Virtual machines in development should be stored in a separate development catalog that is not shared with other organizations.

    As a note of reference, there is already a default System organization in the vCloud Director environment. The administrative organization being created here is different from the built-in System organization since it can actually create vApps and catalogs and share them.

    Make sure that when you create the administrative organization you set it up to allow publishing of catalogs.

    4.1.2 Standard OrganizationsCreate an organization for each tenant of the vCloud as necessary. Each of the standard organizations should be created with the following considerations:

    Cannot publish global catalogs

    Use system defaults for SMTP

    Use system defaults for notification settings

    Use leases, quotas, and limits meeting the providers requirements

    4.2 Establish Networking OptionsWorkloads in the cloud consumer resources will have network connectivity at two levels:

    External networks, used to connect to the outside. These are mapped to vSphere networks.

    InternalorNAT-routednetworks,usedtofacilitateVM-to-VMcommunicationwithinacloud.Thesearebackedby vCloud Director network pools.

  • T e c h n i c a l W h i T e P a P e R / 2 5

    VMware vCloudArchitecting a vCloud

    4.2.1 External NetworksAnexternalnetworkprovidesconnectivityoutsideanorganizationthroughanexisting,preconfigured

    vSphere network port group. The vSphere port groups can be created using standard vSwitch port groups, vNetworkDistributedSwitchportgroups,ortheCiscoNexus1000V.

    In a public vCloud, these preconfigured port groups will provide access through the Internet to customer networks,typicallyusingVPNorMPLSterminations.

    When creating an external network, make sure to have sufficient vSphere port groups created and made available for virtual machine access in the vCloud.

    4.2.2 Network PoolsvCloud Director creates a private network as needed from a pool of networks to facilitate VM-to-VM

    communicationandNAT-routednetworks.vCloudDirectorsupportsoneofthreemethodstobacknetworkpools:

    vSphere port group. vCloud Director uses one of many existing, preconfigured vSphere networks. The networksthemselvescanhaveVLANtaggingforadditionalsecurity.

    VLAN.vCloudDirectorautomaticallyusesVLANtaggingfromarangeprovidedtosegmentnetworkstocreate internal networks (organization and vApp networks) as needed. This assumes that vCloud Director and allthemanagedhostshaveaccesstotheVLANsonthephysicalnetwork.

    vCloudDirectorNetworkIsolation.vCloudDirectorautomaticallycreatesinternalnetworksusingMAC-in-MACencapsulation.

    The following table compares the three options for a network pool.

    ConsideRATion vspheRe poRT gRoup BACked

    VlAn BACked vCloud neTWoRk isolATion BACked

    How it works Isolated port groups must be created and exist on all hosts in cluster

    Uses range of available, unusedVLANsdedicated for vCloud

    Overlay network (with network ID) created for each isolated network

    Advantages Only option compatible withCiscoNexus1000V

    Best network performance

    vCloud Director creates portgroups as needed

    Optionally requires one VLANpervCloudDirectorNetworkIsolation backed network pool

    More secure than VLANbackedoption

    vCloud Director creates portgroups as needed

    Disadvantages Requires manual creation and management of portgroups

    Possible to use a portgroup that is in fact not isolated

    Chance of running out ofVLANIDs

    Overhead required for MAC-in-MAC encapsulation

    Table 5. Network Pool Options

  • T e c h n i c a l W h i T e P a P e R / 2 6

    VMware vCloudArchitecting a vCloud

    Considerations when using a vSphere port group-backed network pool include:

    Standard or distributed virtual switches may be used.

    vCloud Director does not automatically create port groups. You must manually create these ahead of time for vCloud Director to use.

    ConsiderationswhenusingaVLAN-backednetworkpoolinclude:

    OrganizationandvAppnetworkscreatedbyvCloudDirectoroutofVLANbackednetworkpoolsareprivatetoan organization or vApp, respectively.

    HostsintheclusterbackingtheprovidervDCusedbytheorganizationvDCmustbeconnectedtoVLANtrunkports.

    vNetworkdistributedswitchesarerequiredforallhostsandtheclusterbackingtheprovidervDCusedbytheorganization vDC that draws from the network pool.

    vCloud Director creates port groups automatically as needed.

    ConsiderationswhenusingavCloudNetworkIsolation-backednetworkpoolinclude:

    vNetworkdistributedswitchesarerequiredforallhostsandtheclusterbackingtheprovidervDCusedbytheorganization vDC that draws from the network pool.

    IncreasetheMTUsizeofthephysicalswitchesaswellasthevNetworkdistributedswitchestoatleast1524toaccommodatetheadditionalMACheaderinformationusedbyvCloudDirectorNetworkIsolationlinks.Failureto increase the MTU size could affect performance due to packet fragmentation affecting network throughput of virtual machines hosted on the vCloud infrastructure.

    SpecifyaVLANIDfortheMAC-in-MACtransportnetwork(thisisoptionalbutrecommendedforsecurity).LeavingthisblankwilldefaulttoVLAN0.

    vCloudDirectorcreatesportgroupsautomaticallyonvNetworkdistributedswitchesasneeded.

    PrivatenetworksbackedbyvCloudDirectorNetworkIsolationusefewerVLANIDs.

    OrganizationandvAppnetworkscreatedbyvCloudDirectoroutofvCloudDirectorNetworkIsolationbackednetwork pools are private with respect to an organization or vApp, respectively.

    4.2.3 Cisco Nexus 1000V ConsiderationsInvCloudDirector1.0,theCiscoNexus1000VisonlysupportedwiththevSphereportgroup-backedoptionfornetworkpools,whichalsohappenstobetheleastflexible.ThisisalsotruefortheVMwarevNetworkStandardSwitch,whilethevNetworkDistributedSwitchwillsupportallnetworktypes.

    CiscoNexus1000VrequiresavNetworkDistributedSwitchandthereforevSphereEnterprisePluslicensing.

    TheCiscoNexus1000VistypicallydeployedinavSphereenvironmenttoprovideincreasednetworkvisibility,commonmanagementandadvancedlayer2securityandqualityofservicefunctionalityforvirtualnetworking.As vCloud Director ideally uses dynamic, automatically provisioned, isolated networks; internally this means these requirements for management and security do not directly apply to network pools. However they are relevant to the external networks where traffic enters and exits the vCloud.

    The next sections walk go into detail on networking options for external networks and network pools, and discuss public vs. private vCloud perspectives.

    4.3 Establish Networking OptionsPublic vCloud Example4.3.1 External NetworksReferencing the Service Definition for a Public Cloud, all service tiers use a shared public Internet connection. To fulfill this, create a single external provider network. Make sure to give the network a descriptive name, such as Provider-Internet, for the case here. You will connect this external network to a vSphere port group that is actually connected to the Internet. Make sure you have the IP information for the physical network you have attachedto,includingthenetworkmask,defaultgateway,andDNSinformation.Lastly,youwillcreateapool

  • T e c h n i c a l W h i T e P a P e R / 2 7

    VMware vCloudArchitecting a vCloud

    of static IP addresses that will be consumed by vShield Edge appliances (that facilitate a routed connection) each time you connect an organization network to this external network.

    For sizing purposes, you should create a large enough IP address pool so that each of your organizations can haveaccesstoanexternalnetwork.PertheServiceDefinition,theestimatednumberoforganizationsfor1,500virtualmachinesis25organizations,somakesureyouhaveatleast25IPaddressesinyourstaticIPpool.MoreIP addresses should be set aside if you plan to allow inbound access into organizations.

    4.3.2 Network PoolsIn addition to access to external networks, each organization in a public vCloud will have organization-specific privatenetworks.vCloudDirectorinstantiatesIsolatedL2networksthroughtheuseofnetworkpools.

    Create a single large network pool for all organizations to share, and limit the use of this network pool when you createeachindividualorganization.ThenetworkpoolcreatedwillusevCloudNetworkIsolationforseparatingthetraffic.ThiswilluseanexistingvNetworkDistributedSwitchpreviouslycreatedforconnectinghosts.UseaVLANtofurthersegregateallofthevCloudDirectorNetworkIsolationtrafficinatransportnetworkfromtherest of the infrastructure.

    Because the network pools will be used by both the external organization network and private vApp networks, youwillneedatleast11networksinthenetworkpoolperorganization.Tenofthenetworksinthepoolwillbeforthe private vApp networks according to the Service Definition for a Public Cloud. One of the networks will be usedfortheprotectedexternalorganizationnetwork.Giventheestimateof25organizations,youneedatleast275networksinthepool.Thereisalimitationofamaximumof4096networksinanetworkpoolduetotheportlimitationonthevNetworkDistributedSwitch.EphemeralportsinavNetworkDistributedSwitcharealsolimitedto1016perSwitchandpervCenterserver,furtherlimitingthenumberofnetworksthatcanbeinstantiatedfromanetworkpool.WhenconnectingthenetworkpooltoavNetworkDistributedSwitch,makesureyouhaveenoughfreeportsleftontheswitch(atleast275).

    vCloud Datacenter

    Organization ACME Corp.

    Org Net:

    ACME-Private

    Private Internal

    Org Net: ACME-InternetPrivate Routed

    Provider-Internet

    Network Pool

    Figure 10. Example Diagram of Provider Networking for a Public vCloud

    4.3.3 Organization NetworksCreate two different organization networks for each organization, one external organization network and one private internal organization network. You can do this as one step in the vCloud Director UI wizard by selecting the default (recommended) option when creating a new organization network. When naming an organization network, it is a best practice to start with the organization name and a hyphen, for example, ACME-Internet.

  • T e c h n i c a l W h i T e P a P e R / 2 8

    VMware vCloudArchitecting a vCloud

    Per the Service Definition for Public Cloud, the external network will be connected as a routed connection that willleveragevShieldEdgeforfirewallingandNATtokeeptrafficseparatedfromotherorganizationsonthesame external provider network. Both the external organization network and the internal organization networks willleveragethesamevCloudDirectorNetworkIsolationnetworkpoolpreviouslyestablished.Forboththeinternal network and the external network, you will need to provide a range of IP addresses and associated networkinformation.Sincebothofthenetworkswillbeprivatenetworks,youcanuseRFC1918addressesforboth static IP address pools.

    The Service Definition for Public Cloud defines a limit of external connections with a maximum of 8 IP addresses, so you should provide a range of 8 IP addresses only when creating the static IP address pool for the external network. For the private network, you can make the static IP address pool as large as desired. Typically, a full RFC1918classCisusedfortheprivatenetworkIPpool.

    The last step is to add external public IP addresses to the vShield Edge configuration on the external organization network. By selecting Configure Services on the external organization network, you can add 8 public IP addresses that can be used by that particular organization. These IP addresses should come from the same subnet as the network that you assigned to the systems external network static IP pool.

    Figure 11. Configure External IPs

    4.3.4 Cisco Nexus 1000V Considerations

    ItisimportanttonotethatvCloudDirectorisdesignedforsecuremulti-tenancy,andLayer2networksarenotshared between customers for organization and vApp networks. External networks can be dedicated to customers(forexample,MPLSVPNs)andvShieldEdgeisavailabletosecurelysharenetworkssuchasacommoninternetVLAN.ThesecapabilitiesshouldbeconsideredwhendeterminingwhethertheCiscoNexus1000VisrequiredinavCloudDirectordeployment.

    WhereithasbeendeterminedthattheCiscoNexus1000Visarequirement,eitheroperationallyortechnically,therecommendedapproachistousetheNexus1000vforexternalnetworksandaVMwarevNetworkDistributed Switch for network pools. This approach has the advantage of providing advanced functionality where required, without limiting the flexibility of vCloud Director networking.

  • T e c h n i c a l W h i T e P a P e R / 2 9

    VMware vCloudArchitecting a vCloud

    UsingtheCiscoNexus1000VforvCloudDirectornetworkpoolsisnotrecommendedbecausethisrequiresincreasedadministrativeoverhead;theCiscoNexus1000VworksonlywithvSphereportgroup-backednetworkpools and introduces scalability limits. In this model, organization and vApp networks cannot be created dynamicallybecauseportprofilesneedtobedefinedontheCiscoNexus1000VbeforebeingaddedtovCloudDirector. To maintain isolation within these internal networks, each port group will need to be configured with a VLANID,whichgiventhelimitof512activeVLANsacrossallvirtualethernetmodule(VEMs)managedbyaCiscoNexus1000V,alsopotentiallylimitsthetotalnumberofnetworkingpools.Thisisparticularlytrueifonevirtualsupervisormodule(VSM)ismanagingVEMsinmultiplevCloudresourcegroups,andthe802.1qstandarditselfislimitedto4096VLANs.

    vCloudDirectorNetworkIsolationbacked-networkpoolsisanapproachtoaddressthesescalabilitylimitsbyproviding isolation of internal vCloud Director networks using MAC-in-MAC encapsulation over a transport network.InsteadofindividualVLANs,vCloudDirectorNetworkIsolationnetworkIDsaredynamicallyassignedtotheseencapsulatednetworksbyvCloudDirector.VLANbackednetworkpoolsisanotheroptionwherearangeofVLANIDsisallocatedtovCloudDirector,whichwillthenassigntheseVLANstoorganizationandvAppnetworks, as required. So while it shares the same scalability limits as port group backed, it reduces manual administratorsetup.VLANandvCloudDirectorNetworkIsolationbackednetworkpoolsareonlysupportedwiththevNetworkDistributedSwitch.

    ThefollowingdiagramillustratestherecommendeddeploymentmodelwiththeCiscoNexus1000V,usedforexternal networks only.

    pNIC

    pNIC

    VLAN 110

    VLAN 120

    VLAN 130

    VLAN 140

    VLAN 150

    Org A External

    Org B External

    Org C External

    Org A VPN

    Org B VPN

    pNIC

    pNIC

    VLAN 210

    VLAN 220

    VLAN 230

    VLAN 298

    VLAN 299

    OrgNet1

    OrgNet2

    OrgNet3

    VCD-NI Pool A

    VCD-NI Pool B

    Mgmt PortGroup

    Service PortGroup

    pNIC

    pNIC

    VLAN 10

    VLAN 20

    CorePhysicalSwitching

    CorePhysicalSwitching

    Resource Group

    VMware vDS

    Nexus 1000v vDS

    VMware vSwitch

    Figure 12. vCloud Director Logical Networking w/ Cisco Nexus 1000V

  • T e c h n i c a l W h i T e P a P e R / 3 0

    VMware vCloudArchitecting a vCloud

    4.4 Establish Networking OptionsPrivate vCloud Example4.4.1 External NetworksIn general, for a private vCloud, the networking needs are comparable to that of a public vCloud and oftentimes simplified, representing a subset. As such, direct connections from inside the organization to the networking backboneprovidedbytheenterpriseareallthatisnecessary.ThisisanalogoustoextendingawirefromthenetworkswitchthatcontainsthenetworkorVLANtobeusedallthewaythroughthecloudlayerstotheorganizationandintothevApp.OneofthesedirectnetworksmustbeestablishedforeachnetworkorVLANtobe used in the private vCloud.

    Enterprise vCloud

    Organization Software Design

    Org Net:

    Internal Network

    Private Internal (optional)

    Org Net: External AccessPrivate Direct

    Corporate Backbone

    Network Pool

    Figure 13. Example Diagram of Provider Networking for a Private vCloud

    An important differentiation in a private vCloud vs. a public vCloud is the external network and organization external network.

    At least one external network is required to enable organization external networks to access resources outside of the vCloud Director resourcesthe Internet for public cloud deployments and an internal (local) network for private cloud deployments. It is a network that already exists within the address space used by the enterprise.

    To establish this network, follow the wizard, filling in the network mask, default gateway and other specifications oftheLANsegmentasrequired.Whenbuildingthis,specifyenoughaddressspaceforuseasstaticassignments,asthisiswherevCloudDirectordrawsPublicIPPooladdressesfrom.Agoodstartingrangeis30addresses that do not conflict with existing addresses in use, or ranges already committed for DHCP.

    Note: Static IP Pool address space is not used for DHCP, but the function is similar to that. This pool will be used to provision NAT-type connectivity between the organizations and the cloud services below it.

    4.4.2 Network PoolsYou will need a network in the network pool for every private organization network and external organization network in the vCloud environment. The Service Definition for a Private Cloud calls for one external organization network and the ability for the organization to create private vApp networks. Since there is no minimum called outintheServiceDefinitionforthenumberofvAppnetworksagoodnumberofnetworkstostartoutwithis10perorganization.Makeyournetworkpoolaslargeasthenumberoforganizationstimes10.

  • T e c h n i c a l W h i T e P a P e R / 3 1

    VMware vCloudArchitecting a vCloud

    4.4.3 Organization NetworksAt least one organization external network is required to connect vApps created within the organization to other vApps and/or the networking layers beyond the Private vCloud.

    To accomplish this, create an external network in the Cloud Resources section (under Manage & Monitor of the System Administration section of the vCloud Director UI). In the wizard, be sure to select a direct connection. This external network maps to an existing vSphere network for virtual machine use as defined in the External Networkssection(above).

    Other networking options are available, like a routed organization external network, and could be used, but add complexity to the design that is normally not needed. For the purpose of this design there are no additional network requirements. For more information on adding additional network options, refer to the vCloud Director Administrators Guide.

    4.4.4 Cisco Nexus 1000V ConsiderationsTheCiscoNexus1000VisapplicableasaswitchingfabricintheEnterprise.ThecaveatsexpressedinthepublicvCloudsectionforCiscoNexus1000ValsoapplytotheprivatevCloud.Theprimarydifferenceisthatthenetworking rails used as external networks will likely be simpler that those shown for a public vCloud. For example,thereslikelytobeonlyasinglebackboneLANtoconnecttothatsalsothepathtotheInternet,ascompared to a public vCloud where there will be multiple, distinct network paths.

    Insummary,theCiscoNexus1000VisapplicabletoprivatevCloudimplementationsasaswitchingbackboneforexternalnetworksonly,torepresenttheoneormorecoreLANsthatleadtotherestofthebusinessand/orInternet.

    4.5 Establish Organization Virtual DatacentersAn organization virtual datacenter allocates resources from a provider virtual datacenter and makes it available for use for a given organization. Multiple organization virtual datacenters can take from the same provider virtual datacenter. An organization can have multiple organization virtual datacenters.

    Resources are taken from a provider virtual datacenter and allocated to an organization virtual datacenter using one of three resource allocation models:

    Pay as you go. Resources are only reserved and committed for vApps as vApps are created. There is no upfront reservation of resources.

    Allocation.Abaselineamount(guarantee)ofresourcesfromtheprovidervirtualdatacenterisreservedforthe organization virtual datacenters exclusive use. An additional percentage of resources is available to oversubscribe CPU and memory, but this taps into compute resources that are shared by other organization virtual datacenters drawing from the provider virtual datacenter.

    Reservation. All resources assigned to the organization virtual datacenter are reserved exclusively for the organization virtual datacenters use.

    With all of the above models, the organization can be limited to deploy a certain number of virtual machines. Or, this can also be set to unlimited.

    The first organization virtual datacenter to be created should be an administration organization virtual datacenterforusebytheadministrationorganization.TheallocationmodelissettoPayasyougosoasnottotake resources from other organization virtual datacenters until they are needed.

    Subsequent organization virtual datacenters should be created to serve the organizations previously established. In selecting the appropriate allocation model, the Service Definition and organizations use cases of workloads should be taken into consideration. Take into account anticipated workload capacity, discussed further in the Capacity Management section.

  • T e c h n i c a l W h i T e P a P e R / 3 2

    VMware vCloudArchitecting a vCloud

    4.5.1 Public vCloud ConsiderationsThe organization virtual datacenter allocation model maps directly to a corresponding vCenter Chargeback billing model:

    Pay as you go. Pricing can be set per virtual machine, and a corresponding speed of a vCPU equivalent can