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