Document how to use network templates
Change-Id: I7b17acc56f4d35efce06164a67c2968f75f75b99 Related-Bug: #1514365
This commit is contained in:
parent
07de27f5c6
commit
bd16b84602
Binary file not shown.
After Width: | Height: | Size: 55 KiB |
|
@ -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>`_.
|
|
@ -12,7 +12,7 @@ User documentation
|
|||
releases
|
||||
installation
|
||||
user
|
||||
cluster_operations
|
||||
advanced_operations
|
||||
licenses
|
||||
appendix
|
||||
|
||||
|
|
|
@ -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
|
Loading…
Reference in New Issue