Document how to use network templates

Change-Id: I7b17acc56f4d35efce06164a67c2968f75f75b99
Related-Bug: #1514365
This commit is contained in:
Simon Pasquier 2016-05-13 13:43:02 +02:00
parent 07de27f5c6
commit bd16b84602
4 changed files with 228 additions and 4 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 55 KiB

View File

@ -1,7 +1,12 @@
.. _advanced_user_guide:
Advanced Operations
===================
.. _cluster_operations:
Cluster Operations
==================
------------------
Because of certain limitations in the current implementation of the Fuel plugin, it is necessary to
perform some manual operations after the Elasticsearch cluster is scaled up or scaled down.
@ -29,7 +34,7 @@ to one node, are used as examples. Your mileage may vary but the
principal of (re)configuring the replication factor of the indices should remain the same.
Scaling Up
-----------
^^^^^^^^^^
The problem the manual operation aims to address is that the replication factor for the old
indices is not updated automatically by the plugin when a new node is added in the cluster. If you
@ -64,7 +69,7 @@ Note that replicating the old indices on the new node(s) will increase the load
cluster as well as the size required to store the data.
Scaling down
------------
^^^^^^^^^^^^
Similarly, after a scale-down the *number_of_replicas* of all indices must be
aligned with the new size of the cluster. Not doing so will be reported by LMA as a critical
@ -83,3 +88,42 @@ status for the Elasticsearch cluster::
[root@node-1 ~]# curl <VIP>:9200/_cat/indices?v
health status index pri rep docs.count ....
green open log-2016.02.04 5 2 1934581 ....
.. _network_templates:
Deployment using network templates
----------------------------------
By default, the Elasticsearch-Kibana cluster is deployed on the Fuel management
network. If this behavior doesn't meet your needs, you can leverage the
Fuel `network templates
<https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates>`_
to use a different network instead.
Here is a network template example that defines a new network named `monitoring`.
.. literalinclude:: ./network_template.yaml
You can use this configuration as a starting point and adapt it to your setup.
The deployment of the environment happens as described in the :ref:`User Guide
<user_guide>` except that before deploying the environment, you have to:
* Upload the network template::
$ fuel2 network-template upload -f network_template.yaml <ENVIRONMENT_ID>
* Allocate an IP subnet for the `monitoring` network::
$ fuel2 network-group create -N <ENVIRONMENT_ID> -C 10.109.5.0/24 monitoring
* Adjust the IP range through the Fuel user interface (optional).
.. image:: ../images/network_group_configuration.png
:width: 800
:align: center
* Deploy the environment.
For more details, please refer to the official `Fuel documentation
<https://docs.mirantis.com/openstack/fuel/fuel-8.0/operations.html#using-networking-templates>`_.

View File

@ -12,7 +12,7 @@ User documentation
releases
installation
user
cluster_operations
advanced_operations
licenses
appendix

View File

@ -0,0 +1,180 @@
adv_net_template:
default:
network_assignments:
fuelweb_admin:
ep: br-fw-admin
management:
ep: br-mgmt
private:
ep: br-mesh
public:
ep: br-ex
storage:
ep: br-storage
monitoring:
ep: br-monitoring
network_scheme:
admin:
endpoints:
- br-fw-admin
roles:
admin/pxe: br-fw-admin
fw-admin: br-fw-admin
transformations:
- action: add-br
name: br-fw-admin
- action: add-port
bridge: br-fw-admin
name: <% if1 %>
mgmt:
endpoints:
- br-mgmt
roles:
ceilometer/api: br-mgmt
cinder/api: br-mgmt
glance/api: br-mgmt
heat/api: br-mgmt
horizon: br-mgmt
keystone/api: br-mgmt
management: br-mgmt
mgmt/api: br-mgmt
mgmt/corosync: br-mgmt
mgmt/database: br-mgmt
mgmt/memcache: br-mgmt
mgmt/messaging: br-mgmt
mgmt/vip: br-mgmt
mongo/db: br-mgmt
murano/api: br-mgmt
neutron/api: br-mgmt
neutron/private: br-mgmt
nova/api: br-mgmt
nova/migration: br-mgmt
rados_gw_management_vip: br-mgmt
sahara/api: br-mgmt
swift/api: br-mgmt
swift/replication: br-mgmt
transformations:
- action: add-br
name: br-mgmt
- action: add-port
bridge: br-mgmt
name: <% if3 %>
private:
endpoints:
- br-mesh
roles:
neutron/mesh: br-mesh
transformations:
- action: add-br
name: br-mesh
- action: add-port
bridge: br-mesh
name: <% if4 %>
public:
endpoints:
- br-mesh
- br-ex
roles:
ceph/radosgw: br-ex
cinder/api: br-ex
ex: br-ex
neutron/floating: br-floating
public/vip: br-ex
transformations:
- action: add-br
name: br-ex
- action: add-br
name: br-floating
provider: ovs
- action: add-patch
bridges:
- br-floating
- br-ex
mtu: 65000
provider: ovs
- action: add-port
bridge: br-ex
name: <% if2 %>
storage:
endpoints:
- br-storage
roles:
ceph/replication: br-storage
cinder/iscsi: br-storage
storage: br-storage
swift/replication: br-storage
transformations:
- action: add-br
name: br-storage
- action: add-port
bridge: br-storage
name: <% if5 %>
monitoring:
endpoints:
- br-monitoring
roles:
monitoring: br-monitoring
elasticsearch: br-monitoring
influxdb_vip: br-monitoring
infrastructure_alerting: br-monitoring
transformations:
- action: add-br
name: br-monitoring
- action: add-port
bridge: br-monitoring
name: <% if3 %>.101
nic_mapping:
default:
# fw-admin
if1: eth0
# public
if2: eth1
# management + monitoring (VLAN: 101)
if3: eth2
# private
if4: eth3
# storage
if5: eth4
templates_for_node_role:
# The following roles supports deployments using Neutron with tunneling segmentation
# and Cinder with LVM over iSCSI
cinder:
- admin
- mgmt
- private
- storage
- monitoring
compute:
- admin
- mgmt
- private
- storage
- monitoring
controller:
- admin
- mgmt
- public
- private
- storage
- monitoring
elasticsearch_kibana:
- admin
- mgmt
- public
- private
- storage
- monitoring
influxdb_grafana:
- admin
- mgmt
- public
- private
- storage
- monitoring
infrastructure_alerting:
- admin
- mgmt
- public
- private
- storage
- monitoring