github.com/makyo/juju@v0.0.0-20160425123129-2608902037e9/doc/azure-provider.txt (about) 1 Introduction 2 ============ 3 4 This document describes how the Azure provider works; how Azure concepts are 5 mapped, and some high-level descriptions of how the provider is implemented. 6 7 8 References 9 ========== 10 11 Service Management REST API Reference 12 http://msdn.microsoft.com/library/azure/ee460799.aspx 13 14 "What is a cloud service?" (This is out of date, but still somewhat useful.) 15 http://azure.microsoft.com/en-us/documentation/articles/cloud-services-what-is/ 16 17 Cloud Services, Virtual Machines and Virtual Network SLA 18 https://www.microsoft.com/windowsazure/sla/ 19 20 21 Azure Concepts 22 ============== 23 24 Affinity Group 25 26 An Affinity Group is used to group VMs, storage, etc. within a location. 27 It is possible to simply associate each of the entities with the same 28 location, however it is recommended to use an Affinity Group. Azure may 29 then locate entities as close to each other as possible within a data- 30 centre, as opposed to just being in the same data-centre. 31 32 We create an Affinty Group per model called "juju-<modelname>-ag". 33 34 Cloud Service 35 36 (AKA "Hosted Service" in API) 37 38 A Cloud Service is a container for VMs, and is the publicly-addressable 39 entity for Azure's compute service. Each Cloud Service must have a 40 globally-unique name, which is used to derive its domain name. A Cloud- 41 Service has only one domain name and public IP address. 42 43 We currently prefix Cloud Services that we create with "juju-<envname>-", 44 and randomly generate the remainder of the name. 45 46 Deployment 47 48 A Cloud Service may have up to two deployments: Production and Staging. 49 The deployments may be swapped at runtime, so that a Staging deployment 50 can be upgraded whilst maintaining a Production deployment that can be 51 swapped back to should the upgrade go wrong. 52 53 We currently only ever create a Production deployment. 54 55 Role 56 57 For our purposes, a Role describes a Virtual Machine (VM). The description 58 includes the hostname, initial username and password, attached disk(s), 59 network configuration, and which Availability Set (if any) the role belongs 60 to. 61 62 A role may have multiple instances (Role Instance), however we only ever 63 have one per role. The Juju "Instance" implementation for the Azure 64 provider maps to a Role Instance, although the implementation details 65 differ between the current and the original implementation. 66 67 A role/instance has only Virtual IPs (VIPs), i.e. internal addresses. The 68 role may expose "endpoints", i.e. TCP/UDP ports. Each port may be exposed 69 by at most one role in a Cloud Service, unless that port is part of a load- 70 balancing set. When a client connects to the containing Cloud Service's 71 address + the endpoint port, the traffic will be routed to the role 72 instance(s) that expose that endpoint. 73 74 Availability Set 75 76 Each Cloud Service has zero or more Availability Sets within it; a Role 77 can be assigned to at most one of them. As long as there are at least two 78 Roles in the same Availability Set, then Azure will guarantee at least 79 99.95% availability under the Azure Service Level Agreement (SLA). 80 81 We create a single Availability Set for each Cloud Service, and all roles 82 are added to it. Thus, all Juju-deployed services are, by default, covered 83 by the Azure SLA. 84 85 86 Azure provider implementation 87 ============================= 88 89 Bootstrapping 90 91 Before the Azure provider can bootstrap a model, it expects one and 92 only one thing to be pre-existing: a storage account; this storage account 93 is used for the model's Storage() implementation. When the 94 model is bootstrapped, the provider creates an affinity group and a 95 virtual network. 96 97 The Azure provider now has two modes in which it can operate, configured at 98 bootstrap time with the "availability-sets-enabled" boolean attribute. If it 99 is true (henceforth "azure-mode"), then support for multiple Roles per Cloud- 100 Service is enabled; otherwise there is a single Role per Cloud Service. By 101 default, we set availability-sets-enabled=true for new model. 102 103 Note: by setting availability-sets-enabled=false, you will gain the abililty 104 to place units on any machine at the cost of losing Azure's SLA guarantees. 105 See "Starting instances" below for more details on what is prevented by 106 azure-mode. 107 108 Starting instances 109 110 When *not* in azure-mode, the provider will simply create a new Cloud- 111 Service, Deployment, and Role. The user may use placement directives and 112 add machines like in any other provider, but they will not have any 113 availability guarantees provided by Azure. 114 115 When in azure-mode, the provider must impose several restrictions to 116 achieve availability guarantees: 117 - placement (i.e. --to <machine>) is disallowed, 118 - "juju add-machine" is disallowed. 119 Thus, an instance can only be created in response to adding a unit to a 120 service, and an instance can contain only units of a single service type. 121 122 Instances are deployed to the same Cloud Service as the other instances 123 of its "Distribution Group" (a new Juju provisioning concept introduced 124 to support azure-mode, Availability Zones, etc.), or a new Cloud Service 125 if the group is empty. For a controller, the Distribution Group is the 126 set of instances that contain other controller instances; for any other 127 instance, the Distribution Group is the set of instances that contain units 128 of the same service that the instance is being provisioned for. All new 129 instances are added to the same Availability Set within the Cloud Service. 130 131 Instance mapping 132 133 In the Azure provider, we map instance IDs to a Role within a Cloud- 134 Service. The instance-id format is servicename-rolename, where servicename 135 is the name of the Cloud Service and rolename is the name of the Role. We 136 only ever have one Deployment in a Cloud Service, so it is inferred. 137 138 Originally the provider was written such that instance IDs mapped only to 139 Cloud Services, as originally there was a one-to-one correspondence between 140 Juju-deployed Cloud Services and Roles. This has had to change to cater for 141 Azure's recommended high availability practices. We maintain backwards 142 compatability with old deployments; existing Cloud Services are assumed 143 to have a single role within. 144 145 Exposing Services 146 147 Because a Cloud Service has a single public IP, and instances within do 148 not have their own, exposed services will have their ports load balanced 149 across each instance whose unit opens the port. Load balancing only takes 150 effect when connecting to the public (Cloud Service) address. 151 152 In azure-mode, the controller and API server ports are automatically 153 load-balanced. When HA Juju is enabled, this means that API client 154 connections will be load balanced automatically by Azure. 155 156 In azure-mode, the SSH port is also load-balanced so that port 22 may be 157 used uniformly across providers. To ensure that "juju ssh" connects to 158 the correct instance, we connect to the instance's internal address by 159 first proxying through the API server. 160