Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
ContentsContents
Deployment Guide using Cloud Lifecycle Manager
  1. I Planning an Installation using Cloud Lifecycle Manager
    1. 1 Registering SLES
    2. 2 Hardware and Software Support Matrix
    3. 3 Recommended Hardware Minimums for the Example Configurations
    4. 4 High Availability
  2. II Cloud Lifecycle Manager Overview
    1. 5 Input Model
    2. 6 Configuration Objects
    3. 7 Other Topics
    4. 8 Configuration Processor Information Files
    5. 9 Example Configurations
    6. 10 Modifying Example Configurations for Compute Nodes
    7. 11 Modifying Example Configurations for Object Storage using Swift
    8. 12 Alternative Configurations
  3. III Pre-Installation
    1. 13 Overview
    2. 14 Pre-Installation Checklist
    3. 15 Installing the Cloud Lifecycle Manager server
    4. 16 Installing and Setting Up an SMT Server on the Cloud Lifecycle Manager server (Optional)
    5. 17 Software Repository Setup
    6. 18 Boot from SAN and Multipath Configuration
  4. IV Cloud Installation
    1. 19 Overview
    2. 20 Preparing for Stand-Alone Deployment
    3. 21 Installing with the Install UI
    4. 22 Using Git for Configuration Management
    5. 23 Installing a Stand-Alone Cloud Lifecycle Manager
    6. 24 Installing Mid-scale and Entry-scale KVM
    7. 25 DNS Service Installation Overview
    8. 26 Magnum Overview
    9. 27 Installing ESX Computes and OVSvAPP
    10. 28 Integrating NSX for vSphere
    11. 29 Installing Baremetal (Ironic)
    12. 30 Installation for SUSE OpenStack Cloud Entry-scale Cloud with Swift Only
    13. 31 Installing SLES Compute
    14. 32 Installing manila and Creating manila Shares
    15. 33 Installing SUSE CaaS Platform heat Templates
    16. 34 Installing SUSE CaaS Platform v4 using terraform
    17. 35 Integrations
    18. 36 Troubleshooting the Installation
    19. 37 Troubleshooting the ESX
  5. V Post-Installation
    1. 38 Post Installation Tasks
    2. 39 UI Verification
    3. 40 Installing OpenStack Clients
    4. 41 Configuring Transport Layer Security (TLS)
    5. 42 Configuring Availability Zones
    6. 43 Configuring Load Balancer as a Service
    7. 44 Other Common Post-Installation Tasks
  6. VI Support
    1. 45 FAQ
    2. 46 Support
    3. 47 Applying PTFs (Program Temporary Fixes) Provided by SUSE L3 Support
    4. 48 Testing PTFs (Program Temporary Fixes) on a Single Node
Navigation
Applies to SUSE OpenStack Cloud 9

25 DNS Service Installation Overview Edit source

The SUSE OpenStack Cloud DNS Service supports several different backends for domain name service. The choice of backend must be included in the deployment model before the SUSE OpenStack Cloud install is completed.

Warning
Warning

By default any user in the project is allowed to manage a DNS domain. This can be changed by updating the Policy.json file for designate.

The backends that are available within the DNS Service are separated into two categories, self-contained and external.

Table 25.1: DNS Backends
CategoryBackendDescriptionRecommended For
Self-containedBIND 9.x All components necessary will be installed and configured as part of the SUSE OpenStack Cloud install. POCs and customers who wish to keep cloud and traditional DNS separated.
ExternalInfoBlox The authoritative DNS server itself is external to SUSE OpenStack Cloud. Management and configuration is out of scope for the Cloud Lifecycle Manager but remains the responsibility of the customer. Customers who wish to integrate with their existing DNS infrastructure.

25.1 Installing the DNS Service with BIND Edit source

SUSE OpenStack Cloud DNS Service defaults to the BIND back-end if another back-end is not configured for domain name service. BIND will be deployed to one or more control planes clusters. The following configuration example shows how the BIND service is installed.

25.1.1 Configuring the Back-end Edit source

Ensure the DNS Service components and the BIND component have been placed on a cluster. BIND can be placed on a cluster separate from the other DNS service components.

control-planes:
          - name: control-plane-1
          region-name: region1

          clusters:
          - name: cluster1
          service-components:
          - lifecycle-manager
          - mariadb
          - ip-cluster
          - apache2
          - ...
          - designate-api
          - designate-central
          - designate-pool-manager
          - designate-zone-manager
          - designate-mdns
          - designate-client
          - bind

Updating the Input Model

When the back-end is configured, add bind-ext to the file network_groups.yml.

  1. Edit ~/openstack/my_cloud/definition/data/network_groups.yml to add bind-ext to component-endpoints.

    name: EXTERNAL-API
    hostname-suffix: extapi
    component-endpoints:
    - bind-ext
  2. Save the file.

25.2 Install the DNS Service with PowerDNS Edit source

25.2.1 Installing DNS Service with PowerDNS Edit source

SUSE OpenStack Cloud DNS Service and PowerDNS can be installed together instead of the default BIND backend. PowerDNS will be deployed to one or more control planes clusters. The following configuration example shows how the PowerDNS service is installed.

25.2.2 Configure the Backend Edit source

To configure the backend for PowerDNS, follow these steps.

  1. Ensure the DNS Service components and the PowerDNS component have been placed on a cluster. PowerDNS may be placed on a separate cluster to the other DNS Service components. Ensure the default bind component has been removed.

    control-planes:
              - name: control-plane-1
              region-name: region1
    
              clusters:
              - name: cluster1
              service-components:
              - lifecycle-manager
              - mariadb
              - ip-cluster
              - apache2
              - ...
              - designate-api
              - designate-central
              - designate-pool-manager
              - designate-zone-manager
              - designate-mdns
              - designate-client
              - powerdns
  2. Edit the ~/openstack/my_cloud/definitions/data/network_groups.yml file to include the powerdns-ext.

    - name: EXTERNAL-API
    hostname-suffix: extapi
    component-endpoints:
     - powerdns-ext
    load-balancers:
     - provider: ip-cluster
  3. Edit the ~/openstack/my_cloud/definitions/data/firewall_rules.yml to allow UDP/TCP access.

    	    - name: DNSudp
          # network-groups lists the network group names that the rules apply to
          network-groups:
          - EXTERNAL-API
          rules:
          - type: allow
            # range of remote addresses in CIDR format that this rule applies to
            remote-ip-prefix:  0.0.0.0/0
            port-range-min: 53
            port-range-max: 53
            protocol: udp
    
        - name: DNStcp
          # network-groups lists the network group names that the rules apply to
          network-groups:
          - EXTERNAL-API
          rules:
          - type: allow
            # range of remote addresses in CIDR format that this rule applies to
            remote-ip-prefix:  0.0.0.0/0
            port-range-min: 53
            port-range-max: 53
            protocol: tcp

Please see Book “Operations Guide CLM”, Chapter 10 “Managing Networking”, Section 10.3 “DNS Service Overview”, Section 10.3.2 “designate Initial Configuration” for post-installation DNS Service configuration.

25.3 Configure DNS Domain and NS Records Edit source

To configure the default DNS domain and Name Server records for the default pool, follow these steps.

  1. Ensure that designate_config.yml file is present in the ~/openstack/my_cloud/definition/data/designate folder. If the file or folder is not present, create the folder and copy designate_config.yml file from one of the example input models (for example, ~/openstack/examples/entry-scale-kvm/data/designate/designate_config.yml).

  2. Modify the dns_domain and/or ns_records entries in the designate_config.yml file.

    data:
    dns_domain: example.org.
    ns_records:
        hostname: ns1.example.org.
        priority: 1
        hostname: ns2.example.org.
        priority: 2
  3. Edit your input model's control_plane.yml file to include DESIGNATE-CONFIG-CP1 in configuration-data section.

    control-planes:
       - name: control-plane-1
         region-name: region1
         lifecycle-manager-target
         configuration-data:
            - DESIGNATE-CONFIG-CP1
            - NEUTRON-CONFIG-CP1
  4. Continue your cloud deployment by reviewing and committing your changes.

    $ git add ~/openstack/my_cloud/definition/data/designate/designate_config.yml
    $ git commit -m "Adding DNS Domain and NS Records"
Note
Note

In an entry-scale model (Section 9.3.1, “Entry-Scale Cloud”), you will have 3 ns_records since the DNS service runs on all three control planes.

In a mid-scale model (Section 9.3.3, “Single-Region Mid-Size Model”) or dedicated metering, monitoring and logging model (Section 9.3.2, “Entry Scale Cloud with Metering and Monitoring Services”), the above example would be correct since there are only two controller nodes.

25.4 Migrate Zone/Pool to Worker/Producer after Upgrade Edit source

After upgrade, the following steps may be used to migrate the zone/pool scheme to the worker/producer scheme:

  1. Log in to the Cloud Lifecycle Manager.

  2. Edit the file ~/openstack/my_cloud/definitions/data/control_plane.yml to replace designate-pool-manager to designate-worker and designate-zone-manager to designate-producer

    control-planes:
              - name: control-plane-1
              region-name: region1
    
              clusters:
              - name: cluster1
              service-components:
              - lifecycle-manager
              - mariadb
              - ip-cluster
              - apache2
              - ...
              - designate-api
              - designate-central
              - designate-worker
              - designate-producer
              - designate-mdns
              - designate-client
              - powerdns
  3. Commit your changes to git:

    ardana > cd ~/openstack/ardana/ansible
    ardana > git commit -m "COMMIT_MESSAGE"
  4. Run the configuration processor:

    ardana > cd ~/openstack/ardana/ansible
    ardana > ansible-playbook -i hosts/localhost config-processor-run.yml
  5. Create a deployment directory:

    ardana > cd ~/openstack/ardana/ansible
    ardana > ansible-playbook -i hosts/localhost ready-deployment.yml
  6. Run the designate-migrate.yml playbook to migrate the designate services:

    ardana > cd ~/scratch/ansible/next/ardana/ansible
    ardana > ansible-playbook -i hosts/verb_hosts designate-migrate.yml
Print this page