Hard merge with Mirantis/fuel-docs -> fuel-3.1 branch
This commit is contained in:
Pavel Lechenko
parent
a3a1f826d5
commit
3b8b662880
|
|
@ -1,11 +1,12 @@
|
|||
.. _About_Fuel:
|
||||
|
||||
============
|
||||
About Fuel
|
||||
============
|
||||
|
||||
.. _contents:: :local:
|
||||
|
||||
.. _include:: /pages/about-fuel/0010-introduction.rst
|
||||
.. include: /pages/about-fuel/0010-introduction.rst
|
||||
.. include:: /pages/about-fuel/0020-what-is-fuel.rst
|
||||
.. include:: /pages/about-fuel/0030-how-it-works.rst
|
||||
.. include:: /pages/about-fuel/0040-reference-topologies.rst
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
.. index:: Release Notes
|
||||
|
||||
.. _Release_Notes:
|
||||
|
||||
=============
|
||||
Release Notes
|
||||
=============
|
||||
|
||||
.. include:: /pages/release-notes/v3-1-grizzly.rst
|
||||
.. include /pages/release-notes/v3-0-grizzly.rst
|
||||
.. include /pages/release-notes/v2-1-folsom.rst
|
||||
.. include /pages/release-notes/v2-0-folsom.rst
|
||||
.. include /pages/release-notes/v1-0-essex.rst
|
||||
|
||||
|
|
@ -1,7 +1,10 @@
|
|||
.. _Reference-Architecture:
|
||||
.. index:: Reference Architectures
|
||||
|
||||
Reference Architecture
|
||||
======================
|
||||
.. _Reference-Architectures:
|
||||
|
||||
=======================
|
||||
Reference Architectures
|
||||
=======================
|
||||
|
||||
.. include:: /pages/reference-architecture/0010-overview.rst
|
||||
.. include:: /pages/reference-architecture/0015-closer-look.rst
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
.. index:: Deploy using UI
|
||||
|
||||
.. _Create-Cluster-UI:
|
||||
|
||||
============================================
|
||||
Create an OpenStack cluster using Fuel UI
|
||||
============================================
|
||||
|
||||
.. include:: /pages/installation-fuel-ui/install.rst
|
||||
.. include:: /pages/installation-fuel-ui/networks.rst
|
||||
.. include:: /pages/installation-fuel-ui/network-issues.rst
|
||||
.. include:: /pages/installation-fuel-ui/post-install-healthchecks.rst
|
||||
.. include:: /pages/installation-fuel-ui/red_hat_openstack.rst
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
.. index:: Deploy using CLI
|
||||
|
||||
.. _Deploy-Cluster-CLI:
|
||||
|
||||
==========================================
|
||||
Deploy an OpenStack cluster using Fuel CLI
|
||||
==========================================
|
||||
|
||||
.. contents: :local:
|
||||
|
||||
.. include: /pages/installation-fuel-cli/0000-preamble.rst
|
||||
.. include: /pages/installation-fuel-cli/0010-introduction.rst
|
||||
.. include: /pages/installation-fuel-cli/0015-before-you-start.rst
|
||||
.. include: /pages/installation-fuel-cli/0020-machines.rst
|
||||
.. include: /pages/installation-fuel-cli/0057-prepare-for-deployment.rst
|
||||
.. include:: /pages/installation-fuel-cli/0060-understand-the-manifest.rst
|
||||
.. include:: /pages/installation-fuel-cli/0070-orchestration.rst
|
||||
.. include:: /pages/installation-fuel-cli/0080-testing-openstack.rst
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
.. index:: Production Considerations
|
||||
|
||||
.. _Production:
|
||||
|
||||
=========================
|
||||
Production Considerations
|
||||
=========================
|
||||
|
||||
|
|
@ -7,3 +10,4 @@ Production Considerations
|
|||
.. include:: /pages/production-considerations/0015-sizing-hardware.rst
|
||||
.. include:: /pages/production-considerations/0020-deployment-pipeline.rst
|
||||
.. include:: /pages/production-considerations/0030-large-deployments.rst
|
||||
.. include /pages/production-considerations/0040-post-install-healthchecks.rst
|
||||
|
|
@ -1,5 +1,10 @@
|
|||
.. _Production:
|
||||
:orphan:
|
||||
|
||||
.. index:: Advanced Topics
|
||||
|
||||
.. _Advanced:
|
||||
|
||||
=============================
|
||||
Advanced Configuration Topics
|
||||
=============================
|
||||
|
||||
|
|
@ -1,5 +1,8 @@
|
|||
.. index:: FAQ (Frequently Asked Questions)
|
||||
|
||||
.. _FAQ:
|
||||
|
||||
================================
|
||||
FAQ (Frequently Asked Questions)
|
||||
================================
|
||||
|
||||
|
|
@ -10,5 +13,6 @@ FAQ (Frequently Asked Questions)
|
|||
.. include:: /pages/frequently-asked-questions/0070-common-technical-issues.rst
|
||||
.. include:: /pages/frequently-asked-questions/0010-rabbitmq.rst
|
||||
.. include:: /pages/frequently-asked-questions/0020-galera.rst
|
||||
.. include:: /pages/frequently-asked-questions/0040-corosync-crashes.rst
|
||||
.. include:: /pages/frequently-asked-questions/0080-other-questions.rst
|
||||
|
||||
12
README.md
12
README.md
|
|
@ -1,5 +1,5 @@
|
|||
FUEL™ for OpenStack Documentation
|
||||
===
|
||||
=================================
|
||||
|
||||
This repository contains the FUEL™ for OpenStack user and administrator guides. For more details, see the [FUEL™ for OpenStack portal](http://fuel.mirantis.com "FUEL™ for OpenStack portal").
|
||||
|
||||
|
|
@ -17,14 +17,21 @@ Prerequisites
|
|||
To get started, you need to install Sphinx and necessary extensions:
|
||||
|
||||
sudo easy_install -U Sphinx
|
||||
sudo easy_install -U cloud_sptheme
|
||||
sudo easy_install -U sphinxcontrib-fancybox
|
||||
sudo easy_install -U rst2pdf
|
||||
sudo easy_install -U sphinxcontrib-blockdiag
|
||||
sudo easy_install -U sphinxcontrib-actdiag
|
||||
sudo easy_install -U sphinxcontrib-seqdiag
|
||||
sudo easy_install -U sphinxcontrib-nwdiag
|
||||
sudo easy_install -U sphinxcontrib-plantuml
|
||||
|
||||
Plus you will need to install [PlantUML](http://plantuml.sourceforge.net/ "PlantUML") and [ImageMagick](http://www.imagemagick.org/ "ImageMagick").
|
||||
|
||||
To install PlantUML you should do:
|
||||
|
||||
sudo wget http://sourceforge.net/projects/plantuml/files/plantuml.jar/download /sbin/plantuml.jar
|
||||
|
||||
To edit SVG images we use [Inkscape](http://inkscape.org/ "Inkscape") but you may use any other SVG-capable tool you like. We're not picky.
|
||||
|
||||
Building
|
||||
|
|
@ -40,5 +47,4 @@ To generate the PDF file run this:
|
|||
|
||||
You will find generated HTML documentation at:
|
||||
|
||||
_build/html
|
||||
|
||||
_build/html
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
|
|
@ -0,0 +1,20 @@
|
|||
<?xml version="1.1" encoding="UTF-8" standalone="no"?>
|
||||
<svg width="1008px" height="516px" xmlns="http://www.w3.org/2000/svg" version="1.1">
|
||||
<title>iCloud</title>
|
||||
<description>Created with Sketch (http://www.bohemiancoding.com/sketch)</description>
|
||||
<defs></defs>
|
||||
<g fill="none" id="Main Page">
|
||||
<path id="Rectangle" d="M187,371 L187,515 L500,515 L500,371 L187,371" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Rectangle decoration" d="" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval" d="M222,392 C249,392 272,369 272,342 C272,314 249,292 222,292 C194,292 172,314 172,342 C172,369 194,392 222,392" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval decoration" d="" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval" d="M187,515 C231,515 267,479 267,435 C267,390 231,355 187,355 C142,355 107,390 107,435 C107,479 142,515 187,515" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval decoration" d="" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval" d="M376,471 C442,471 496,417 496,351 C496,284 442,231 376,231 C309,231 256,284 256,351 C256,417 309,471 376,471" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval decoration" d="" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval" d="M500,515 C541,515 575,481 575,440 C575,398 541,365 500,365 C458,365 425,398 425,440 C425,481 458,515 500,515" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval decoration" d="" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval" d="M605,125 C604,120 604,116 604,112 C604,84 626,62 654,62 C670,62 685,70 694,82 C710,35 755,1 808,1 C874,1 928,54 928,121 C928,125 927,129 927,134 C928,134 930,134 932,134 C973,134 1007,167 1007,209 C1007,250 973,284 932,284 C931,284 619,284 619,284 C574,283 539,247 539,204 C539,164 567,131 605,125 L605,125" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
<path id="Oval decoration" d="" stroke="rgb(0,0,0)" stroke-width="1" fill="none"></path>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 2.2 KiB |
|
Before Width: | Height: | Size: 83 KiB After Width: | Height: | Size: 83 KiB |
|
|
@ -0,0 +1,429 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
viewBox="0.0 0.0 766.0 412.0"
|
||||
fill="none"
|
||||
stroke="none"
|
||||
stroke-linecap="square"
|
||||
stroke-miterlimit="10"
|
||||
id="svg2"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
width="100%"
|
||||
height="100%"
|
||||
sodipodi:docname="060-deployment-compact-w_quantum.svg">
|
||||
<metadata
|
||||
id="metadata103">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs
|
||||
id="defs101" />
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1061"
|
||||
id="namedview99"
|
||||
showgrid="true"
|
||||
showguides="false"
|
||||
inkscape:snap-global="false"
|
||||
inkscape:zoom="1.0560446"
|
||||
inkscape:cx="404.5968"
|
||||
inkscape:cy="165.88193"
|
||||
inkscape:window-x="1362"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="g7">
|
||||
<inkscape:grid
|
||||
type="xygrid"
|
||||
id="grid3118" />
|
||||
</sodipodi:namedview>
|
||||
<clipPath
|
||||
id="p.0">
|
||||
<path
|
||||
d="m0 0l766.0 0l0 412.0l-766.0 0l0 -412.0z"
|
||||
clip-rule="nonzero"
|
||||
id="path5" />
|
||||
</clipPath>
|
||||
<g
|
||||
clip-path="url(#p.0)"
|
||||
id="g7">
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m0 0l766.8714 0l0 412.93176l-766.8714 0z"
|
||||
fill-rule="nonzero"
|
||||
id="path9" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m24.945854 253.45992l0 0c0 -16.270264 13.189648 -29.459915 29.459908 -29.459915l175.09592 0c7.813263 0 15.306503 3.1038055 20.831314 8.628601c5.5247955 5.524811 8.628586 13.018051 8.628586 20.831314l0 117.836075c0 16.270264 -13.189636 29.45993 -29.4599 29.45993l-175.09592 0l0 0c-16.27026 0 -29.459908 -13.189667 -29.459908 -29.45993z"
|
||||
fill-rule="nonzero"
|
||||
id="path11" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m24.945854 253.45992l0 0c0 -16.270264 13.189648 -29.459915 29.459908 -29.459915l175.09592 0c7.813263 0 15.306503 3.1038055 20.831314 8.628601c5.5247955 5.524811 8.628586 13.018051 8.628586 20.831314l0 117.836075c0 16.270264 -13.189636 29.45993 -29.4599 29.45993l-175.09592 0l0 0c-16.27026 0 -29.459908 -13.189667 -29.459908 -29.45993z"
|
||||
fill-rule="nonzero"
|
||||
id="path13" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m10.961601 37.192184l0 0c0 -16.122398 13.069786 -29.192184 29.192184 -29.192184l175.63138 0c7.7422485 0 15.167389 3.0755968 20.641998 8.550194c5.474594 5.474596 8.550186 12.899742 8.550186 20.64199l0 116.76524c0 16.12239 -13.069794 29.192184 -29.192184 29.192184l-175.63138 0l0 0c-16.122398 0 -29.192184 -13.069794 -29.192184 -29.192184z"
|
||||
fill-rule="nonzero"
|
||||
id="path15" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m10.961601 37.192184l0 0c0 -16.122398 13.069786 -29.192184 29.192184 -29.192184l175.63138 0c7.7422485 0 15.167389 3.0755968 20.641998 8.550194c5.474594 5.474596 8.550186 12.899742 8.550186 20.64199l0 116.76524c0 16.12239 -13.069794 29.192184 -29.192184 29.192184l-175.63138 0l0 0c-16.122398 0 -29.192184 -13.069794 -29.192184 -29.192184z"
|
||||
fill-rule="nonzero"
|
||||
id="path17" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m43.623013 58.72714l0 0c0 -2.8904915 2.3432045 -5.2337 5.2337 -5.2337l154.19403 0c1.3880615 0 2.719284 0.55140686 3.7007904 1.5329132c0.98150635 0.98151016 1.5329132 2.3127213 1.5329132 3.7007866l0 20.93417c0 2.8904953 -2.343216 5.2337036 -5.2337036 5.2337036l-154.19403 0l0 0c-2.8904953 0 -5.2337 -2.3432083 -5.2337 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path21" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m43.623013 58.72714l0 0c0 -2.8904915 2.3432045 -5.2337 5.2337 -5.2337l154.19403 0c1.3880615 0 2.719284 0.55140686 3.7007904 1.5329132c0.98150635 0.98151016 1.5329132 2.3127213 1.5329132 3.7007866l0 20.93417c0 2.8904953 -2.343216 5.2337036 -5.2337036 5.2337036l-154.19403 0l0 0c-2.8904953 0 -5.2337 -2.3432083 -5.2337 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path23" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m43.623013 100.887245l0 0c0 -2.8904953 2.3432045 -5.2337036 5.2337 -5.2337036l154.19403 0c1.3880615 0 2.719284 0.55140686 3.7007904 1.5329208c0.98150635 0.98150635 1.5329132 2.3127213 1.5329132 3.7007828l0 20.934174c0 2.8904877 -2.343216 5.233696 -5.2337036 5.233696l-154.19403 0l0 0c-2.8904953 0 -5.2337 -2.3432083 -5.2337 -5.233696z"
|
||||
fill-rule="nonzero"
|
||||
id="path27" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m43.623013 100.887245l0 0c0 -2.8904953 2.3432045 -5.2337036 5.2337 -5.2337036l154.19403 0c1.3880615 0 2.719284 0.55140686 3.7007904 1.5329208c0.98150635 0.98150635 1.5329132 2.3127213 1.5329132 3.7007828l0 20.934174c0 2.8904877 -2.343216 5.233696 -5.2337036 5.233696l-154.19403 0l0 0c-2.8904953 0 -5.2337 -2.3432083 -5.2337 -5.233696z"
|
||||
fill-rule="nonzero"
|
||||
id="path29" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m8.945853 237.45992l0 0c0 -16.270264 13.189651 -29.459915 29.459908 -29.459915l175.09592 0c7.813263 0 15.306503 3.1038055 20.831314 8.628601c5.5247955 5.524811 8.628601 13.018051 8.628601 20.831314l0 117.836075c0 16.270264 -13.1896515 29.45993 -29.459915 29.45993l-175.09592 0l0 0c-16.270258 0 -29.459908 -13.189667 -29.459908 -29.45993z"
|
||||
fill-rule="nonzero"
|
||||
id="path33" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m8.945853 237.45992l0 0c0 -16.270264 13.189651 -29.459915 29.459908 -29.459915l175.09592 0c7.813263 0 15.306503 3.1038055 20.831314 8.628601c5.5247955 5.524811 8.628601 13.018051 8.628601 20.831314l0 117.836075c0 16.270264 -13.1896515 29.45993 -29.459915 29.45993l-175.09592 0l0 0c-16.270258 0 -29.459908 -13.189667 -29.459908 -29.45993z"
|
||||
fill-rule="nonzero"
|
||||
id="path35" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m42.82309 268.63528l0 0c0 -2.890503 2.3432045 -5.2337036 5.2337 -5.2337036l154.19402 0c1.3880768 0 2.719284 0.5513916 3.7007904 1.532898c0.98150635 0.98150635 1.5329132 2.3127441 1.5329132 3.7008057l0 20.934174c0 2.8904724 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19402 0l0 0c-2.8904953 0 -5.2337 -2.3432312 -5.2337 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path39" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m42.82309 268.63528l0 0c0 -2.890503 2.3432045 -5.2337036 5.2337 -5.2337036l154.19402 0c1.3880768 0 2.719284 0.5513916 3.7007904 1.532898c0.98150635 0.98150635 1.5329132 2.3127441 1.5329132 3.7008057l0 20.934174c0 2.8904724 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19402 0l0 0c-2.8904953 0 -5.2337 -2.3432312 -5.2337 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path41" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m266.9616 38.04258l0 0c0 -16.1224 13.069763 -29.192186 29.19217 -29.192186l175.63138 0c7.7422485 0 15.167389 3.0755968 20.641998 8.550194c5.474579 5.474596 8.550171 12.899744 8.550171 20.641993l0 116.765236c0 16.122406 -13.069794 29.192184 -29.19217 29.192184l-175.63138 0l0 0c-16.122406 0 -29.19217 -13.069778 -29.19217 -29.192184z"
|
||||
fill-rule="nonzero"
|
||||
id="path45" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m266.9616 38.04258l0 0c0 -16.1224 13.069763 -29.192186 29.19217 -29.192186l175.63138 0c7.7422485 0 15.167389 3.0755968 20.641998 8.550194c5.474579 5.474596 8.550171 12.899744 8.550171 20.641993l0 116.765236c0 16.122406 -13.069794 29.192184 -29.19217 29.192184l-175.63138 0l0 0c-16.122406 0 -29.19217 -13.069778 -29.19217 -29.192184z"
|
||||
fill-rule="nonzero"
|
||||
id="path47" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m299.3774 58.72714l0 0c0 -2.8904915 2.3432007 -5.2337 5.2337036 -5.2337l154.194 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98151016 1.532898 2.3127213 1.532898 3.7007866l0 20.93417c0 2.8904953 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.194 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path51" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m299.3774 58.72714l0 0c0 -2.8904915 2.3432007 -5.2337 5.2337036 -5.2337l154.194 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98151016 1.532898 2.3127213 1.532898 3.7007866l0 20.93417c0 2.8904953 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.194 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path53" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m299.3774 100.887245l0 0c0 -2.8904953 2.3432007 -5.2337036 5.2337036 -5.2337036l154.194 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329208c0.98150635 0.98150635 1.532898 2.3127213 1.532898 3.7007828l0 20.934174c0 2.8904877 -2.3432007 5.233696 -5.2337036 5.233696l-154.194 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.233696z"
|
||||
fill-rule="nonzero"
|
||||
id="path57" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m299.3774 100.887245l0 0c0 -2.8904953 2.3432007 -5.2337036 5.2337036 -5.2337036l154.194 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329208c0.98150635 0.98150635 1.532898 2.3127213 1.532898 3.7007828l0 20.934174c0 2.8904877 -2.3432007 5.233696 -5.2337036 5.233696l-154.194 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.233696z"
|
||||
fill-rule="nonzero"
|
||||
id="path59" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m522.5189 38.04258l0 0c0 -16.1224 13.069763 -29.192186 29.1922 -29.192186l175.63135 0c7.7422485 0 15.167358 3.0755968 20.641968 8.550194c5.4746094 5.474596 8.550232 12.899744 8.550232 20.641993l0 116.765236c0 16.122406 -13.069824 29.192184 -29.1922 29.192184l-175.63135 0l0 0c-16.122437 0 -29.1922 -13.069778 -29.1922 -29.192184z"
|
||||
fill-rule="nonzero"
|
||||
id="path63" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m522.5189 38.04258l0 0c0 -16.1224 13.069763 -29.192186 29.1922 -29.192186l175.63135 0c7.7422485 0 15.167358 3.0755968 20.641968 8.550194c5.4746094 5.474596 8.550232 12.899744 8.550232 20.641993l0 116.765236c0 16.122406 -13.069824 29.192184 -29.1922 29.192184l-175.63135 0l0 0c-16.122437 0 -29.1922 -13.069778 -29.1922 -29.192184z"
|
||||
fill-rule="nonzero"
|
||||
id="path65" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m554.9347 58.72714l0 0c0 -2.8904915 2.3432007 -5.2337 5.2337036 -5.2337l154.19403 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98151016 1.532898 2.3127213 1.532898 3.7007866l0 20.93417c0 2.8904953 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19403 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path69" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m554.9347 58.72714l0 0c0 -2.8904915 2.3432007 -5.2337 5.2337036 -5.2337l154.19403 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98151016 1.532898 2.3127213 1.532898 3.7007866l0 20.93417c0 2.8904953 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19403 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path71" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m554.9347 100.887245l0 0c0 -2.8904953 2.3432007 -5.2337036 5.2337036 -5.2337036l154.19403 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329208c0.98150635 0.98150635 1.532898 2.3127213 1.532898 3.7007828l0 20.934174c0 2.8904877 -2.3432007 5.233696 -5.2337036 5.233696l-154.19403 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.233696z"
|
||||
fill-rule="nonzero"
|
||||
id="path75" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m554.9347 100.887245l0 0c0 -2.8904953 2.3432007 -5.2337036 5.2337036 -5.2337036l154.19403 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329208c0.98150635 0.98150635 1.532898 2.3127213 1.532898 3.7007828l0 20.934174c0 2.8904877 -2.3432007 5.233696 -5.2337036 5.233696l-154.19403 0l0 0c-2.890503 0 -5.2337036 -2.3432083 -5.2337036 -5.233696z"
|
||||
fill-rule="nonzero"
|
||||
id="path77" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m43.623016 145.38068l0 0c0 -2.8904877 2.3432083 -5.2336884 5.2337 -5.2336884l154.19402 0c1.3880768 0 2.719284 0.55140686 3.7007904 1.5329132c0.98150635 0.98150635 1.5329132 2.3127136 1.5329132 3.7007751l0 20.934174c0 2.890503 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19402 0l0 0c-2.8904915 0 -5.2337 -2.3432007 -5.2337 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path81" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m43.623016 145.38068l0 0c0 -2.8904877 2.3432083 -5.2336884 5.2337 -5.2336884l154.19402 0c1.3880768 0 2.719284 0.55140686 3.7007904 1.5329132c0.98150635 0.98150635 1.5329132 2.3127136 1.5329132 3.7007751l0 20.934174c0 2.890503 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19402 0l0 0c-2.8904915 0 -5.2337 -2.3432007 -5.2337 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path83" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m299.3774 145.38068l0 0c0 -2.8904877 2.3432007 -5.2336884 5.2337036 -5.2336884l154.194 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98150635 1.532898 2.3127136 1.532898 3.7007751l0 20.934174c0 2.890503 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.194 0l0 0c-2.890503 0 -5.2337036 -2.3432007 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path87" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m299.3774 145.38068l0 0c0 -2.8904877 2.3432007 -5.2336884 5.2337036 -5.2336884l154.194 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98150635 1.532898 2.3127136 1.532898 3.7007751l0 20.934174c0 2.890503 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.194 0l0 0c-2.890503 0 -5.2337036 -2.3432007 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path89" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m554.9347 145.38068l0 0c0 -2.8904877 2.3432007 -5.2336884 5.2337036 -5.2336884l154.19403 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98150635 1.532898 2.3127136 1.532898 3.7007751l0 20.934174c0 2.890503 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19403 0l0 0c-2.890503 0 -5.2337036 -2.3432007 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path93" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m554.9347 145.38068l0 0c0 -2.8904877 2.3432007 -5.2336884 5.2337036 -5.2336884l154.19403 0c1.3880615 0 2.7192993 0.55140686 3.7008057 1.5329132c0.98150635 0.98150635 1.532898 2.3127136 1.532898 3.7007751l0 20.934174c0 2.890503 -2.3432007 5.2337036 -5.2337036 5.2337036l-154.19403 0l0 0c-2.890503 0 -5.2337036 -2.3432007 -5.2337036 -5.2337036z"
|
||||
fill-rule="nonzero"
|
||||
id="path95" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="130.20284"
|
||||
y="31.80772"
|
||||
id="text3080"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082"
|
||||
x="130.20284"
|
||||
y="31.80772">Controller Node #1</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="384.84326"
|
||||
y="31.852705"
|
||||
id="text3080-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-7"
|
||||
x="384.84326"
|
||||
y="31.852705">Controller Node #2</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="640.04083"
|
||||
y="31.37924"
|
||||
id="text3080-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-0"
|
||||
x="640.04083"
|
||||
y="31.37924">Controller Node #3</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="635.66956"
|
||||
y="73.339157"
|
||||
id="text3114"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116"
|
||||
x="635.66956"
|
||||
y="73.339157">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="635.7666"
|
||||
y="114.70629"
|
||||
id="text3120"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3122"
|
||||
x="635.7666"
|
||||
y="114.70629">Storage</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="636.98688"
|
||||
y="158.98689"
|
||||
id="text3124"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3126"
|
||||
x="636.98688"
|
||||
y="158.98689"
|
||||
style="font-size:14px">Quantum (Hot Standby)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="380.70059"
|
||||
y="72.675148"
|
||||
id="text3114-5"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116-5"
|
||||
x="380.70059"
|
||||
y="72.675148">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="380.79764"
|
||||
y="114.04228"
|
||||
id="text3120-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3122-7"
|
||||
x="380.79764"
|
||||
y="114.04228">Storage</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="382.01791"
|
||||
y="158.32288"
|
||||
id="text3124-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3126-1"
|
||||
x="382.01791"
|
||||
y="158.32288"
|
||||
style="font-size:14px">Quantum (Hot Standby)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="124.68528"
|
||||
y="72.427612"
|
||||
id="text3114-52"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116-7"
|
||||
x="124.68528"
|
||||
y="72.427612">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="124.78233"
|
||||
y="113.79475"
|
||||
id="text3120-6"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3122-1"
|
||||
x="124.78233"
|
||||
y="113.79475">Storage</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="126.0026"
|
||||
y="158.07535"
|
||||
id="text3124-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3126-2"
|
||||
x="126.0026"
|
||||
y="158.07535">Quantum (Active)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="129.94377"
|
||||
y="231.97543"
|
||||
id="text3080-3"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-2"
|
||||
x="129.94377"
|
||||
y="231.97543">Compute Nodes</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="124.87675"
|
||||
y="281.43182"
|
||||
id="text3232"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3234"
|
||||
x="124.87675"
|
||||
y="281.43182">Compute</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 23 KiB |
|
|
@ -0,0 +1,421 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
viewBox="0 0 766 310"
|
||||
stroke-miterlimit="10"
|
||||
id="svg2"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
width="100%"
|
||||
height="100%"
|
||||
sodipodi:docname="deployment-ha-full.svg"
|
||||
style="fill:none;stroke:none">
|
||||
<metadata
|
||||
id="metadata109">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs
|
||||
id="defs107" />
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1366"
|
||||
inkscape:window-height="749"
|
||||
id="namedview105"
|
||||
showgrid="true"
|
||||
inkscape:zoom="1.0560446"
|
||||
inkscape:cx="552.50597"
|
||||
inkscape:cy="258.7624"
|
||||
inkscape:window-x="-4"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="svg2">
|
||||
<inkscape:grid
|
||||
type="xygrid"
|
||||
id="grid4553"
|
||||
empspacing="5"
|
||||
visible="true"
|
||||
enabled="true"
|
||||
snapvisiblegridlinesonly="true" />
|
||||
</sodipodi:namedview>
|
||||
<clipPath
|
||||
id="p.0">
|
||||
<path
|
||||
d="M 0,0 766,0 766,412 0,412 0,0 z"
|
||||
clip-rule="nonzero"
|
||||
id="path5"
|
||||
inkscape:connector-curvature="0" />
|
||||
</clipPath>
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 269.26473,215.30757 0,0 c 0,-9.47938 13.18965,-17.16394 29.4599,-17.16394 l 175.09592,0 c 7.81326,0 15.3065,1.80833 20.83131,5.02719 5.5248,3.21887 8.62861,7.58458 8.62861,12.13675 l 0,68.65367 c 0,9.47939 -13.18966,17.16395 -29.45992,17.16395 l -175.09592,0 0,0 c -16.27025,0 -29.4599,-7.68456 -29.4599,-17.16395 z"
|
||||
id="path33-1-0-6" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:1.53095841;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 269.03021,215.13686 0,0 c 0,-9.51462 13.21609,-17.22775 29.51895,-17.22775 l 175.44686,0 c 7.82892,0 15.33718,1.81506 20.87307,5.04589 5.53587,3.23083 8.6459,7.61277 8.6459,12.18186 l 0,68.90892 c 0,9.51463 -13.2161,17.22776 -29.51897,17.22776 l -175.44686,0 0,0 c -16.30286,0 -29.51895,-7.71313 -29.51895,-17.22776 z"
|
||||
id="path35-7-14-67" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 14.641505,216.30901 0,0 c 0,-9.44856 13.18965,-17.10814 29.4599,-17.10814 l 175.095915,0 c 7.81326,0 15.3065,1.80246 20.83131,5.01085 5.5248,3.20841 8.62861,7.55992 8.62861,12.09729 l 0,68.43048 c 0,9.44857 -13.18966,17.10815 -29.45992,17.10815 l -175.095915,0 0,0 c -16.27025,0 -29.4599,-7.65958 -29.4599,-17.10815 z"
|
||||
id="path33-1-0" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:1.53095841;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 14.406985,216.1941 0,0 c 0,-9.51462 13.21609,-17.22775 29.51895,-17.22775 l 175.446855,0 c 7.82892,0 15.33718,1.81506 20.87307,5.04589 5.53587,3.23083 8.6459,7.61277 8.6459,12.18186 l 0,68.90892 c 0,9.51463 -13.2161,17.22776 -29.51897,17.22776 l -175.446855,0 0,0 c -16.30286,0 -29.51895,-7.71313 -29.51895,-17.22776 z"
|
||||
id="path35-7-14" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 524.94232,216.27622 0,0 c 0,-9.3407 13.18965,-16.91284 29.4599,-16.91284 l 175.09592,0 c 7.81326,0 15.3065,1.78188 20.83131,4.95365 5.5248,3.17178 8.62861,7.47362 8.62861,11.95919 l 0,67.64931 c 0,9.34071 -13.18966,16.91285 -29.45992,16.91285 l -175.09592,0 0,0 c -16.27025,0 -29.4599,-7.57214 -29.4599,-16.91285 z"
|
||||
id="path33-1-0-5" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:1.53095841;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 524.37301,215.52838 0,0 c 0,-9.51462 13.21609,-17.22775 29.51895,-17.22775 l 175.44686,0 c 7.82892,0 15.33718,1.81506 20.87307,5.04589 5.53587,3.23083 8.6459,7.61277 8.6459,12.18186 l 0,68.90892 c 0,9.51463 -13.2161,17.22776 -29.51897,17.22776 l -175.44686,0 0,0 c -16.30286,0 -29.51895,-7.71313 -29.51895,-17.22776 z"
|
||||
id="path35-7-14-6" />
|
||||
<path
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m -1.9291672,-0.42309 766.8713972,0 0,412.93176 -766.8713972,0 z"
|
||||
id="path9" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 9.032434,36.7691 0,0 c 0,-16.1224 13.069786,-29.19219 29.192184,-29.19219 l 175.631372,0 c 7.74225,0 15.16739,3.0756 20.642,8.5502 5.4746,5.47459 8.55019,12.89974 8.55019,20.64199 l 0,116.76523 c 0,16.12239 -13.0698,29.19219 -29.19219,29.19219 l -175.631372,0 0,0 c -16.122398,0 -29.192184,-13.0698 -29.192184,-29.19219 z"
|
||||
id="path15" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 9.032434,36.7691 0,0 c 0,-16.1224 13.069786,-29.19219 29.192184,-29.19219 l 175.631372,0 c 7.74225,0 15.16739,3.0756 20.642,8.5502 5.4746,5.47459 8.55019,12.89974 8.55019,20.64199 l 0,116.76523 c 0,16.12239 -13.0698,29.19219 -29.19219,29.19219 l -175.631372,0 0,0 c -16.122398,0 -29.192184,-13.0698 -29.192184,-29.19219 z"
|
||||
id="path17" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 41.693846,70.30405 0,0 c 0,-2.89049 2.343204,-5.2337 5.2337,-5.2337 l 154.194024,0 c 1.38806,0 2.71929,0.55141 3.70079,1.53292 0.98151,0.98151 1.53292,2.31272 1.53292,3.70078 l 0,20.93417 c 0,2.8905 -2.34322,5.23371 -5.23371,5.23371 l -154.194024,0 0,0 c -2.890495,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path21" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 41.693846,70.30405 0,0 c 0,-2.89049 2.343204,-5.2337 5.2337,-5.2337 l 154.194024,0 c 1.38806,0 2.71929,0.55141 3.70079,1.53292 0.98151,0.98151 1.53292,2.31272 1.53292,3.70078 l 0,20.93417 c 0,2.8905 -2.34322,5.23371 -5.23371,5.23371 l -154.194024,0 0,0 c -2.890495,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path23" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 263.03243,37.61949 0,0 c 0,-16.1224 13.06976,-29.19218 29.19217,-29.19218 l 175.63138,0 c 7.74225,0 15.16739,3.07559 20.642,8.55019 5.47458,5.4746 8.55017,12.89974 8.55017,20.64199 l 0,116.76524 c 0,16.1224 -13.0698,29.19218 -29.19217,29.19218 l -175.63138,0 0,0 c -16.12241,0 -29.19217,-13.06978 -29.19217,-29.19218 z"
|
||||
id="path45" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 263.03243,37.61949 0,0 c 0,-16.1224 13.06976,-29.19218 29.19217,-29.19218 l 175.63138,0 c 7.74225,0 15.16739,3.07559 20.642,8.55019 5.47458,5.4746 8.55017,12.89974 8.55017,20.64199 l 0,116.76524 c 0,16.1224 -13.0698,29.19218 -29.19217,29.19218 l -175.63138,0 0,0 c -16.12241,0 -29.19217,-13.06978 -29.19217,-29.19218 z"
|
||||
id="path47" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 295.44823,70.30405 0,0 c 0,-2.89049 2.3432,-5.2337 5.2337,-5.2337 l 154.194,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53292 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.8905 -2.3432,5.23371 -5.23371,5.23371 l -154.194,0 0,0 c -2.8905,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path51" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 295.44823,70.30405 0,0 c 0,-2.89049 2.3432,-5.2337 5.2337,-5.2337 l 154.194,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53292 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.8905 -2.3432,5.23371 -5.23371,5.23371 l -154.194,0 0,0 c -2.8905,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path53" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 518.58973,37.61949 0,0 c 0,-16.1224 13.06976,-29.19218 29.1922,-29.19218 l 175.63135,0 c 7.74225,0 15.16736,3.07559 20.64197,8.55019 5.47461,5.4746 8.55023,12.89974 8.55023,20.64199 l 0,116.76524 c 0,16.1224 -13.06982,29.19218 -29.1922,29.19218 l -175.63135,0 0,0 c -16.12244,0 -29.1922,-13.06978 -29.1922,-29.19218 z"
|
||||
id="path63" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 518.58973,37.61949 0,0 c 0,-16.1224 13.06976,-29.19218 29.1922,-29.19218 l 175.63135,0 c 7.74225,0 15.16736,3.07559 20.64197,8.55019 5.47461,5.4746 8.55023,12.89974 8.55023,20.64199 l 0,116.76524 c 0,16.1224 -13.06982,29.19218 -29.1922,29.19218 l -175.63135,0 0,0 c -16.12244,0 -29.1922,-13.06978 -29.1922,-29.19218 z"
|
||||
id="path65" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 551.00553,70.30405 0,0 c 0,-2.89049 2.3432,-5.2337 5.2337,-5.2337 l 154.19403,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53292 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.8905 -2.3432,5.23371 -5.23371,5.23371 l -154.19403,0 0,0 c -2.8905,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path69" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 551.00553,70.30405 0,0 c 0,-2.89049 2.3432,-5.2337 5.2337,-5.2337 l 154.19403,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53292 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.8905 -2.3432,5.23371 -5.23371,5.23371 l -154.19403,0 0,0 c -2.8905,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path71" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 41.693849,122.95759 0,0 c 0,-2.89049 2.343208,-5.23369 5.2337,-5.23369 l 154.194021,0 c 1.38807,0 2.71928,0.55141 3.70079,1.53291 0.9815,0.98151 1.53291,2.31272 1.53291,3.70078 l 0,20.93417 c 0,2.89051 -2.3432,5.23371 -5.2337,5.23371 l -154.194021,0 0,0 c -2.890492,0 -5.2337,-2.3432 -5.2337,-5.23371 z"
|
||||
id="path81" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 41.693849,122.95759 0,0 c 0,-2.89049 2.343208,-5.23369 5.2337,-5.23369 l 154.194021,0 c 1.38807,0 2.71928,0.55141 3.70079,1.53291 0.9815,0.98151 1.53291,2.31272 1.53291,3.70078 l 0,20.93417 c 0,2.89051 -2.3432,5.23371 -5.2337,5.23371 l -154.194021,0 0,0 c -2.890492,0 -5.2337,-2.3432 -5.2337,-5.23371 z"
|
||||
id="path83" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 295.44823,122.95759 0,0 c 0,-2.89049 2.3432,-5.23369 5.2337,-5.23369 l 154.194,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53291 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.89051 -2.3432,5.23371 -5.23371,5.23371 l -154.194,0 0,0 c -2.8905,0 -5.2337,-2.3432 -5.2337,-5.23371 z"
|
||||
id="path87" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 295.44823,122.95759 0,0 c 0,-2.89049 2.3432,-5.23369 5.2337,-5.23369 l 154.194,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53291 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.89051 -2.3432,5.23371 -5.23371,5.23371 l -154.194,0 0,0 c -2.8905,0 -5.2337,-2.3432 -5.2337,-5.23371 z"
|
||||
id="path89" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 551.00553,122.95759 0,0 c 0,-2.89049 2.3432,-5.23369 5.2337,-5.23369 l 154.19403,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53291 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.89051 -2.3432,5.23371 -5.23371,5.23371 l -154.19403,0 0,0 c -2.8905,0 -5.2337,-2.3432 -5.2337,-5.23371 z"
|
||||
id="path93" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 551.00553,122.95759 0,0 c 0,-2.89049 2.3432,-5.23369 5.2337,-5.23369 l 154.19403,0 c 1.38807,0 2.7193,0.55141 3.70081,1.53291 0.98151,0.98151 1.5329,2.31272 1.5329,3.70078 l 0,20.93417 c 0,2.89051 -2.3432,5.23371 -5.23371,5.23371 l -154.19403,0 0,0 c -2.8905,0 -5.2337,-2.3432 -5.2337,-5.23371 z"
|
||||
id="path95" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="128"
|
||||
y="32"
|
||||
id="text3080"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082"
|
||||
x="128"
|
||||
y="32">Controller Node #1</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="383"
|
||||
y="32"
|
||||
id="text3080-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-7"
|
||||
x="383"
|
||||
y="32">Controller Node #2</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="638"
|
||||
y="32"
|
||||
id="text3080-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-0"
|
||||
x="638"
|
||||
y="32">Controller Node #3</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="631.74036"
|
||||
y="84.916077"
|
||||
id="text3114"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116"
|
||||
x="631.74036"
|
||||
y="84.916077">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="633.05768"
|
||||
y="136.56381"
|
||||
id="text3124"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3126"
|
||||
x="633.05768"
|
||||
y="136.56381"
|
||||
style="font-size:14px">Quantum (Hot Standby)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="376.77145"
|
||||
y="84.252045"
|
||||
id="text3114-5"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116-5"
|
||||
x="376.77145"
|
||||
y="84.252045">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="378.08878"
|
||||
y="135.89978"
|
||||
id="text3124-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3126-1"
|
||||
x="378.08878"
|
||||
y="135.89978"
|
||||
style="font-size:14px">Quantum (Hot Standby)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="122.75611"
|
||||
y="84.004517"
|
||||
id="text3114-52"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116-7"
|
||||
x="122.75611"
|
||||
y="84.004517">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="124.07343"
|
||||
y="135.65225"
|
||||
id="text3124-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3126-2"
|
||||
x="124.07343"
|
||||
y="135.65225">Quantum (Active)</tspan></text>
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 9.069122,210.52809 0,0 c 0,-9.55642 13.18965,-17.30343 29.4599,-17.30343 l 175.095918,0 c 7.81326,0 15.3065,1.82303 20.83131,5.06805 5.5248,3.24503 8.62861,7.64622 8.62861,12.23538 l 0,69.21165 c 0,9.55643 -13.18966,17.30345 -29.45992,17.30345 l -175.095918,0 0,0 c -16.27025,0 -29.4599,-7.74702 -29.4599,-17.30345 z"
|
||||
id="path33-1" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:1.53095841;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 8.834601,210.56142 0,0 c 0,-9.51462 13.216086,-17.22775 29.518947,-17.22775 l 175.446862,0 c 7.82892,0 15.33718,1.81506 20.87307,5.04589 5.53587,3.23083 8.6459,7.61277 8.6459,12.18186 l 0,68.90892 c 0,9.51463 -13.2161,17.22776 -29.51897,17.22776 l -175.446862,0 0,0 c -16.302861,0 -29.518947,-7.71313 -29.518947,-17.22776 z"
|
||||
id="path35-7" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 42.778957,254.8643 0,0 c 0,-2.8905 2.34321,-5.2337 5.2337,-5.2337 l 154.194013,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.194013,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path39-4" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 42.778957,254.8643 0,0 c 0,-2.8905 2.34321,-5.2337 5.2337,-5.2337 l 154.194013,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.194013,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path41-0" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="128"
|
||||
y="217"
|
||||
id="text3080-3-9"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-2-4"
|
||||
x="128"
|
||||
y="217">Compute Nodes (1+)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="125"
|
||||
y="267"
|
||||
id="text3232-8"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3234-8"
|
||||
x="125"
|
||||
y="267">Compute</tspan></text>
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 264.21022,209.15789 0,0 c 0,-9.43315 13.18965,-17.08024 29.4599,-17.08024 l 175.09592,0 c 7.81326,0 15.3065,1.79952 20.83131,5.00268 5.5248,3.20317 8.62861,7.54759 8.62861,12.07756 l 0,68.31888 c 0,9.43316 -13.18966,17.08025 -29.45992,17.08025 l -175.09592,0 0,0 c -16.27025,0 -29.4599,-7.64709 -29.4599,-17.08025 z"
|
||||
id="path33-1-2" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:1.53095841;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 263.9757,209.07088 0,0 c 0,-9.51462 13.21609,-17.22775 29.51895,-17.22775 l 175.44686,0 c 7.82892,0 15.33718,1.81506 20.87307,5.04589 5.53587,3.23083 8.6459,7.61277 8.6459,12.18186 l 0,68.90892 c 0,9.51463 -13.2161,17.22776 -29.51897,17.22776 l -175.44686,0 0,0 c -16.30286,0 -29.51895,-7.71313 -29.51895,-17.22776 z"
|
||||
id="path35-7-4" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 298.08745,254.71292 0,0 c 0,-2.8905 2.34321,-5.2337 5.2337,-5.2337 l 154.19402,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.19402,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path39-4-5" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 298.08745,254.71292 0,0 c 0,-2.8905 2.34321,-5.2337 5.2337,-5.2337 l 154.19402,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.19402,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path41-0-5" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="383"
|
||||
y="217"
|
||||
id="text3080-3-9-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-2-4-7"
|
||||
x="383"
|
||||
y="217">Swift-Proxy Nodes (2+)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="380.14111"
|
||||
y="267"
|
||||
id="text3232-8-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3234-8-1"
|
||||
x="380.14111"
|
||||
y="267">Swift-Proxy</tspan></text>
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 519.2102,210.21369 0,0 c 0,-9.46397 13.18965,-17.13604 29.4599,-17.13604 l 175.09592,0 c 7.81326,0 15.3065,1.8054 20.83131,5.01902 5.5248,3.21364 8.62861,7.57225 8.62861,12.11702 l 0,68.54207 c 0,9.46398 -13.18966,17.13605 -29.45992,17.13605 l -175.09592,0 0,0 c -16.27025,0 -29.4599,-7.67207 -29.4599,-17.13605 z"
|
||||
id="path33-1-7" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:1.53095841;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 518.97568,210.07088 0,0 c 0,-9.51462 13.21609,-17.22775 29.51895,-17.22775 l 175.44686,0 c 7.82892,0 15.33718,1.81506 20.87307,5.04589 5.53587,3.23083 8.6459,7.61277 8.6459,12.18186 l 0,68.90892 c 0,9.51463 -13.2161,17.22776 -29.51897,17.22776 l -175.44686,0 0,0 c -16.30286,0 -29.51895,-7.71313 -29.51895,-17.22776 z"
|
||||
id="path35-7-1" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 553.25483,254.70855 0,0 c 0,-2.8905 2.34321,-5.2337 5.2337,-5.2337 l 154.19402,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.19402,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path39-4-0" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 553.25483,254.70855 0,0 c 0,-2.8905 2.34321,-5.2337 5.2337,-5.2337 l 154.19402,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.19402,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path41-0-0" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="638"
|
||||
y="217"
|
||||
id="text3080-3-9-8"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-2-4-3"
|
||||
x="638"
|
||||
y="217">Storage Nodes (3+)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="635.14111"
|
||||
y="267"
|
||||
id="text3232-8-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3234-8-5"
|
||||
x="635.14111"
|
||||
y="267">Storage</tspan></text>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 25 KiB |
|
|
@ -0,0 +1,189 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
viewBox="0 0 570 230"
|
||||
stroke-miterlimit="10"
|
||||
id="svg2"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
width="100%"
|
||||
height="100%"
|
||||
sodipodi:docname="deployment-simple.svg"
|
||||
style="fill:none;stroke:none">
|
||||
<metadata
|
||||
id="metadata85">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs
|
||||
id="defs83" />
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1366"
|
||||
inkscape:window-height="749"
|
||||
id="namedview81"
|
||||
showgrid="true"
|
||||
inkscape:zoom="1.358578"
|
||||
inkscape:cx="393.41779"
|
||||
inkscape:cy="191.5123"
|
||||
inkscape:window-x="-4"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="svg2">
|
||||
<inkscape:grid
|
||||
type="xygrid"
|
||||
id="grid3062"
|
||||
empspacing="5"
|
||||
visible="true"
|
||||
enabled="true"
|
||||
snapvisiblegridlinesonly="true" />
|
||||
</sodipodi:namedview>
|
||||
<clipPath
|
||||
id="p.0">
|
||||
<path
|
||||
d="M 0,0 766,0 766,412 0,412 0,0 z"
|
||||
clip-rule="nonzero"
|
||||
id="path5"
|
||||
inkscape:connector-curvature="0" />
|
||||
</clipPath>
|
||||
<path
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 9.9820862,8.67712 766.8714038,0 0,412.93176 -766.8714038,0 z"
|
||||
id="path9" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 316.92794,62.13704 0,0 c 0,-16.27026 13.18965,-29.45991 29.45991,-29.45991 l 175.09592,0 c 7.81327,0 15.3065,3.1038 20.83132,8.6286 5.52479,5.52481 8.62858,13.01805 8.62858,20.83131 l 0,117.83607 c 0,16.27027 -13.18963,29.45993 -29.4599,29.45993 l -175.09592,0 0,0 c -16.27026,0 -29.45991,-13.18966 -29.45991,-29.45993 z"
|
||||
id="path11" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 316.92794,62.13704 0,0 c 0,-16.27026 13.18965,-29.45991 29.45991,-29.45991 l 175.09592,0 c 7.81327,0 15.3065,3.1038 20.83132,8.6286 5.52479,5.52481 8.62858,13.01805 8.62858,20.83131 l 0,117.83607 c 0,16.27027 -13.18963,29.45993 -29.4599,29.45993 l -175.09592,0 0,0 c -16.27026,0 -29.45991,-13.18966 -29.45991,-29.45993 z"
|
||||
id="path13" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 20.943686,45.86931 0,0 c 0,-16.1224 13.06979,-29.19219 29.19219,-29.19219 l 175.631374,0 c 7.74225,0 15.16739,3.0756 20.642,8.5502 5.4746,5.47459 8.55019,12.89974 8.55019,20.64199 l 0,116.76523 c 0,16.12239 -13.0698,29.19219 -29.19219,29.19219 l -175.631374,0 0,0 c -16.1224,0 -29.19219,-13.0698 -29.19219,-29.19219 z"
|
||||
id="path15" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 20.943686,45.86931 0,0 c 0,-16.1224 13.06979,-29.19219 29.19219,-29.19219 l 175.631374,0 c 7.74225,0 15.16739,3.0756 20.642,8.5502 5.4746,5.47459 8.55019,12.89974 8.55019,20.64199 l 0,116.76523 c 0,16.12239 -13.0698,29.19219 -29.19219,29.19219 l -175.631374,0 0,0 c -16.1224,0 -29.19219,-13.0698 -29.19219,-29.19219 z"
|
||||
id="path17" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 53.605096,81.40426 0,0 c 0,-2.89049 2.34321,-5.2337 5.2337,-5.2337 l 154.194034,0 c 1.38806,0 2.71929,0.55141 3.70079,1.53292 0.98151,0.98151 1.53292,2.31272 1.53292,3.70078 l 0,20.93417 c 0,2.8905 -2.34322,5.23371 -5.23371,5.23371 l -154.194034,0 0,0 c -2.89049,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path21" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 53.605096,81.40426 0,0 c 0,-2.89049 2.34321,-5.2337 5.2337,-5.2337 l 154.194034,0 c 1.38806,0 2.71929,0.55141 3.70079,1.53292 0.98151,0.98151 1.53292,2.31272 1.53292,3.70078 l 0,20.93417 c 0,2.8905 -2.34322,5.23371 -5.23371,5.23371 l -154.194034,0 0,0 c -2.89049,0 -5.2337,-2.34321 -5.2337,-5.23371 z"
|
||||
id="path23" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 53.605096,123.56436 0,0 c 0,-2.89049 2.34321,-5.2337 5.2337,-5.2337 l 154.194034,0 c 1.38806,0 2.71929,0.55141 3.70079,1.53293 0.98151,0.9815 1.53292,2.31272 1.53292,3.70077 l 0,20.93418 c 0,2.89049 -2.34322,5.23369 -5.23371,5.23369 l -154.194034,0 0,0 c -2.89049,0 -5.2337,-2.3432 -5.2337,-5.23369 z"
|
||||
id="path27" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 53.605096,123.56436 0,0 c 0,-2.89049 2.34321,-5.2337 5.2337,-5.2337 l 154.194034,0 c 1.38806,0 2.71929,0.55141 3.70079,1.53293 0.98151,0.9815 1.53292,2.31272 1.53292,3.70077 l 0,20.93418 c 0,2.89049 -2.34322,5.23369 -5.23371,5.23369 l -154.194034,0 0,0 c -2.89049,0 -5.2337,-2.3432 -5.2337,-5.23369 z"
|
||||
id="path29" />
|
||||
<path
|
||||
style="fill:#f3f3f3;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 300.92794,46.13704 0,0 c 0,-16.27026 13.18965,-29.45991 29.45991,-29.45991 l 175.09592,0 c 7.81326,0 15.3065,3.1038 20.83131,8.6286 5.5248,5.52481 8.62861,13.01805 8.62861,20.83131 l 0,117.83607 c 0,16.27027 -13.18966,29.45993 -29.45992,29.45993 l -175.09592,0 0,0 c -16.27026,0 -29.45991,-13.18966 -29.45991,-29.45993 z"
|
||||
id="path33" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 300.92794,46.13704 0,0 c 0,-16.27026 13.18965,-29.45991 29.45991,-29.45991 l 175.09592,0 c 7.81326,0 15.3065,3.1038 20.83131,8.6286 5.5248,5.52481 8.62861,13.01805 8.62861,20.83131 l 0,117.83607 c 0,16.27027 -13.18966,29.45993 -29.45992,29.45993 l -175.09592,0 0,0 c -16.27026,0 -29.45991,-13.18966 -29.45991,-29.45993 z"
|
||||
id="path35" />
|
||||
<path
|
||||
style="fill:#fce5cd;fill-rule:nonzero"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 334.80518,81.3124 0,0 c 0,-2.8905 2.3432,-5.2337 5.2337,-5.2337 l 154.19402,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.19402,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path39" />
|
||||
<path
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
inkscape:connector-curvature="0"
|
||||
d="m 334.80518,81.3124 0,0 c 0,-2.8905 2.3432,-5.2337 5.2337,-5.2337 l 154.19402,0 c 1.38808,0 2.71928,0.55139 3.70079,1.53289 0.98151,0.98151 1.53291,2.31275 1.53291,3.70081 l 0,20.93417 c 0,2.89048 -2.3432,5.23371 -5.2337,5.23371 l -154.19402,0 0,0 c -2.89049,0 -5.2337,-2.34323 -5.2337,-5.23371 z"
|
||||
id="path41" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="140"
|
||||
y="40"
|
||||
id="text3080"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082"
|
||||
x="140"
|
||||
y="40">Controller Node</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="134.66737"
|
||||
y="97.104736"
|
||||
id="text3114-52"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3116-7"
|
||||
x="134.66737"
|
||||
y="97.104736">Controller</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="134.76442"
|
||||
y="138.47186"
|
||||
id="text3120-6"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3122-1"
|
||||
x="134.76442"
|
||||
y="138.47186">Storage</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="416.71774"
|
||||
y="39.599487"
|
||||
id="text3080-3"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3082-2"
|
||||
x="416.71774"
|
||||
y="39.599487">Compute Nodes</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="420"
|
||||
y="97"
|
||||
id="text3232"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3234"
|
||||
x="420"
|
||||
y="97">Compute</tspan></text>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 9.5 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 135 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 34 KiB |
|
|
@ -0,0 +1,809 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
viewBox="0.0 0.0 677.0 617.0"
|
||||
fill="none"
|
||||
stroke="none"
|
||||
stroke-linecap="square"
|
||||
stroke-miterlimit="10"
|
||||
id="svg2"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
width="100%"
|
||||
height="100%"
|
||||
sodipodi:docname="010-how-it-works.svg">
|
||||
<metadata
|
||||
id="metadata189">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs
|
||||
id="defs187" />
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1061"
|
||||
id="namedview185"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.5299838"
|
||||
inkscape:cx="243.15373"
|
||||
inkscape:cy="357.96391"
|
||||
inkscape:window-x="1362"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="g7" />
|
||||
<clipPath
|
||||
id="p.0">
|
||||
<path
|
||||
d="m0 0l677.0 0l0 617.0l-677.0 0l0 -617.0z"
|
||||
clip-rule="nonzero"
|
||||
id="path5" />
|
||||
</clipPath>
|
||||
<g
|
||||
clip-path="url(#p.0)"
|
||||
id="g7">
|
||||
<path
|
||||
d="m 98.056803,84.254919 511.842497,0 0,274.771671 -511.842497,0 z"
|
||||
id="path17"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#f3f3f3;fill-rule:nonzero" />
|
||||
<path
|
||||
d="m 375.26603,165.808 0,0 c 0,-8.38921 11.99571,-15.19001 26.79313,-15.19001 l 125.13991,0 c 7.10597,0 13.92091,1.60037 18.94561,4.44905 5.0247,2.84867 7.8475,6.71232 7.8475,10.74096 l 0,60.75824 c 0,8.38922 -11.99565,15.19002 -26.79311,15.19002 l -125.13991,0 c -14.79742,0 -26.79313,-6.8008 -26.79313,-15.19002 z"
|
||||
id="path35"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#f3f3f3;fill-rule:nonzero" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m0 0l677.81366 0l0 617.3438l-677.81366 0z"
|
||||
fill-rule="nonzero"
|
||||
id="path9" />
|
||||
<path
|
||||
d="m 401.31448,205.04533 0,0 c 0,-2.20049 1.78384,-3.98433 3.98431,-3.98433 l 117.44864,0 c 1.05677,0 2.07019,0.41977 2.81739,1.16698 0.74719,0.74721 1.16699,1.76063 1.16699,2.81735 l 0,15.93684 c 0,2.20049 -1.78388,3.98435 -3.98438,3.98435 l -117.44864,0 0,0 c -2.20047,0 -3.98431,-1.78386 -3.98431,-3.98435 z"
|
||||
id="path41"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#d9ead3;fill-rule:nonzero" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m149.68367 395.72647l0 0c0 -3.3050842 2.679306 -5.984375 5.984375 -5.984375l384.40924 0c1.5871582 0 3.109253 0.63049316 4.2315674 1.7527771c1.1223145 1.1222839 1.7528076 2.6444397 1.7528076 4.231598l0 23.936768c0 3.3050537 -2.6793213 5.9843445 -5.984375 5.9843445l-384.40924 0c-3.305069 0 -5.984375 -2.6792908 -5.984375 -5.9843445z"
|
||||
fill-rule="nonzero"
|
||||
id="path11" />
|
||||
<path
|
||||
d="m 401.31448,205.04533 0,0 c 0,-2.20049 1.78384,-3.98433 3.98431,-3.98433 l 117.44864,0 c 1.05677,0 2.07019,0.41977 2.81739,1.16698 0.74719,0.74721 1.16699,1.76063 1.16699,2.81735 l 0,15.93684 c 0,2.20049 -1.78388,3.98435 -3.98438,3.98435 l -117.44864,0 0,0 c -2.20047,0 -3.98431,-1.78386 -3.98431,-3.98435 z"
|
||||
id="path43"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
stroke-dasharray="8.0,6.0"
|
||||
d="m149.68367 395.72647l0 0c0 -3.3050842 2.679306 -5.984375 5.984375 -5.984375l384.40924 0c1.5871582 0 3.109253 0.63049316 4.2315674 1.7527771c1.1223145 1.1222839 1.7528076 2.6444397 1.7528076 4.231598l0 23.936768c0 3.3050537 -2.6793213 5.9843445 -5.984375 5.9843445l-384.40924 0c-3.305069 0 -5.984375 -2.6792908 -5.984375 -5.9843445z"
|
||||
fill-rule="nonzero"
|
||||
id="path13" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m96.7496 84.347084l511.8425 0l0 274.77167l-511.8425 0z"
|
||||
fill-rule="nonzero"
|
||||
id="path19" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m15.999952 496.19083l0 0c0 -12.394043 10.047354 -22.441406 22.441393 -22.441406l133.35344 0c5.951828 0 11.659882 2.3643494 15.868469 6.572937c4.2085724 4.2085876 6.5729218 9.916626 6.5729218 15.868469l0 89.76285c0 12.394043 -10.047348 22.441406 -22.441391 22.441406l-133.35344 0l0 0c-12.394039 0 -22.441393 -10.047363 -22.441393 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path47" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m15.999952 496.19083l0 0c0 -12.394043 10.047354 -22.441406 22.441393 -22.441406l133.35344 0c5.951828 0 11.659882 2.3643494 15.868469 6.572937c4.2085724 4.2085876 6.5729218 9.916626 6.5729218 15.868469l0 89.76285c0 12.394043 -10.047348 22.441406 -22.441391 22.441406l-133.35344 0l0 0c-12.394039 0 -22.441393 -10.047363 -22.441393 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path49" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m3.8131375 484.00397l0 0c0 -12.394043 10.047354 -22.441376 22.441395 -22.441376l133.35344 0c5.951828 0 11.659882 2.3643494 15.868469 6.572937c4.2085724 4.208557 6.5729218 9.916626 6.5729218 15.868439l0 89.76288c0 12.394043 -10.047348 22.441406 -22.441391 22.441406l-133.35344 0l0 0c-12.39404 0 -22.441395 -10.047363 -22.441395 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path51" />
|
||||
<path
|
||||
d="M 242.35639,319.42923 99.848079,495.29486"
|
||||
id="path127"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#ff9900;stroke-width:1.93769789;stroke-linecap:butt;stroke-linejoin:round" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m3.8131375 484.00397l0 0c0 -12.394043 10.047354 -22.441376 22.441395 -22.441376l133.35344 0c5.951828 0 11.659882 2.3643494 15.868469 6.572937c4.2085724 4.208557 6.5729218 9.916626 6.5729218 15.868439l0 89.76288c0 12.394043 -10.047348 22.441406 -22.441391 22.441406l-133.35344 0l0 0c-12.39404 0 -22.441395 -10.047363 -22.441395 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path53" />
|
||||
<path
|
||||
fill="#d9ead3"
|
||||
d="m29.722115 508.6566l0 0c0 -2.2005005 1.7838478 -3.9843445 3.984333 -3.9843445l117.448654 0c1.0567169 0 2.0701447 0.4197693 2.8173523 1.1669922c0.74720764 0.7471924 1.1669769 1.7606201 1.1669769 2.8173523l0 15.936859c0 2.2004395 -1.783844 3.984314 -3.9843292 3.984314l-117.448654 0l0 0c-2.2004852 0 -3.984333 -1.7838745 -3.984333 -3.984314z"
|
||||
fill-rule="nonzero"
|
||||
id="path63" />
|
||||
<path
|
||||
d="M 463.6487,312.15832 103.88288,540.43396"
|
||||
id="path145"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#4a86e8;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m29.722115 508.6566l0 0c0 -2.2005005 1.7838478 -3.9843445 3.984333 -3.9843445l117.448654 0c1.0567169 0 2.0701447 0.4197693 2.8173523 1.1669922c0.74720764 0.7471924 1.1669769 1.7606201 1.1669769 2.8173523l0 15.936859c0 2.2004395 -1.783844 3.984314 -3.9843292 3.984314l-117.448654 0l0 0c-2.2004852 0 -3.984333 -1.7838745 -3.984333 -3.984314z"
|
||||
fill-rule="nonzero"
|
||||
id="path65" />
|
||||
<path
|
||||
fill="#d9ead3"
|
||||
d="m31.046347 552.46094l0 0c0 -3.0876465 2.503027 -5.590637 5.590662 -5.590637l114.23599 0c1.4827423 0 2.9047546 0.58898926 3.9532013 1.6374512c1.0484619 1.0484619 1.6374664 2.470459 1.6374664 3.953186l0 22.362c0 3.0876465 -2.5030212 5.590637 -5.5906677 5.590637l-114.23599 0c-3.087635 0 -5.590662 -2.5029907 -5.590662 -5.590637z"
|
||||
fill-rule="nonzero"
|
||||
id="path69" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m31.046347 552.46094l0 0c0 -3.0876465 2.503027 -5.590637 5.590662 -5.590637l114.23599 0c1.4827423 0 2.9047546 0.58898926 3.9532013 1.6374512c1.0484619 1.0484619 1.6374664 2.470459 1.6374664 3.953186l0 22.362c0 3.0876465 -2.5030212 5.590637 -5.5906677 5.590637l-114.23599 0c-3.087635 0 -5.590662 -2.5029907 -5.590662 -5.590637z"
|
||||
fill-rule="nonzero"
|
||||
id="path71" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m255.17819 496.19083l0 0c0 -12.394043 10.047363 -22.441406 22.441406 -22.441406l133.35342 0c5.9518433 0 11.659882 2.3643494 15.868469 6.572937c4.2085876 4.2085876 6.572937 9.916626 6.572937 15.868469l0 89.76285c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35342 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path77" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m255.17819 496.19083l0 0c0 -12.394043 10.047363 -22.441406 22.441406 -22.441406l133.35342 0c5.9518433 0 11.659882 2.3643494 15.868469 6.572937c4.2085876 4.2085876 6.572937 9.916626 6.572937 15.868469l0 89.76285c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35342 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path79" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m242.99136 484.00397l0 0c0 -12.394043 10.047363 -22.441376 22.441406 -22.441376l133.35342 0c5.9518433 0 11.659882 2.3643494 15.868469 6.572937c4.2085876 4.208557 6.572937 9.916626 6.572937 15.868439l0 89.76288c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35342 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path81" />
|
||||
<path
|
||||
d="m 242.9736,318.47473 83.74139,175.24844"
|
||||
id="path133"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#ff9900;stroke-width:1.98949862;stroke-linecap:butt;stroke-linejoin:round" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m242.99136 484.00397l0 0c0 -12.394043 10.047363 -22.441376 22.441406 -22.441376l133.35342 0c5.9518433 0 11.659882 2.3643494 15.868469 6.572937c4.2085876 4.208557 6.572937 9.916626 6.572937 15.868439l0 89.76288c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35342 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path83" />
|
||||
<path
|
||||
fill="#d9ead3"
|
||||
d="m268.90033 508.6566l0 0c0 -2.2005005 1.7838745 -3.9843445 3.9843445 -3.9843445l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173523 1.1669922c0.7471924 0.7471924 1.1669617 1.7606201 1.1669617 2.8173523l0 15.936859c0 2.2004395 -1.783844 3.984314 -3.984314 3.984314l-117.44867 0l0 0c-2.20047 0 -3.9843445 -1.7838745 -3.9843445 -3.984314z"
|
||||
fill-rule="nonzero"
|
||||
id="path87" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m268.90033 508.6566l0 0c0 -2.2005005 1.7838745 -3.9843445 3.9843445 -3.9843445l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173523 1.1669922c0.7471924 0.7471924 1.1669617 1.7606201 1.1669617 2.8173523l0 15.936859c0 2.2004395 -1.783844 3.984314 -3.984314 3.984314l-117.44867 0l0 0c-2.20047 0 -3.9843445 -1.7838745 -3.9843445 -3.984314z"
|
||||
fill-rule="nonzero"
|
||||
id="path89" />
|
||||
<path
|
||||
fill="#d9ead3"
|
||||
d="m270.22458 551.2552l0 0c0 -3.0876465 2.5030518 -5.590637 5.5906677 -5.590637l114.23602 0c1.482727 0 2.9047241 0.58898926 3.953186 1.6374512c1.0484619 1.0484619 1.6374512 2.470459 1.6374512 3.953186l0 22.362c0 3.0876465 -2.5030212 5.590637 -5.590637 5.590637l-114.23602 0c-3.087616 0 -5.5906677 -2.5029907 -5.5906677 -5.590637z"
|
||||
fill-rule="nonzero"
|
||||
id="path93" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m270.22458 551.2552l0 0c0 -3.0876465 2.5030518 -5.590637 5.5906677 -5.590637l114.23602 0c1.482727 0 2.9047241 0.58898926 3.953186 1.6374512c1.0484619 1.0484619 1.6374512 2.470459 1.6374512 3.953186l0 22.362c0 3.0876465 -2.5030212 5.590637 -5.590637 5.590637l-114.23602 0c-3.087616 0 -5.5906677 -2.5029907 -5.5906677 -5.590637z"
|
||||
fill-rule="nonzero"
|
||||
id="path95" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m491.2857 496.19083l0 0c0 -12.394043 10.047363 -22.441406 22.441406 -22.441406l133.35345 0c5.9518433 0 11.659851 2.3643494 15.868469 6.572937c4.208557 4.2085876 6.572937 9.916626 6.572937 15.868469l0 89.76285c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35345 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path101" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m491.2857 496.19083l0 0c0 -12.394043 10.047363 -22.441406 22.441406 -22.441406l133.35345 0c5.9518433 0 11.659851 2.3643494 15.868469 6.572937c4.208557 4.2085876 6.572937 9.916626 6.572937 15.868469l0 89.76285c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35345 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path103" />
|
||||
<path
|
||||
fill="#f3f3f3"
|
||||
d="m479.0989 484.00397l0 0c0 -12.394043 10.047363 -22.441376 22.441406 -22.441376l133.35342 0c5.9518433 0 11.659912 2.3643494 15.868469 6.572937c4.208557 4.208557 6.572937 9.916626 6.572937 15.868439l0 89.76288c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35342 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path105" />
|
||||
<path
|
||||
d="M 243.94291,318.46364 557.43719,498.52437"
|
||||
id="path139"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#ff9900;stroke-width:1.96732235;stroke-linecap:butt;stroke-linejoin:round" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m479.0989 484.00397l0 0c0 -12.394043 10.047363 -22.441376 22.441406 -22.441376l133.35342 0c5.9518433 0 11.659912 2.3643494 15.868469 6.572937c4.208557 4.208557 6.572937 9.916626 6.572937 15.868439l0 89.76288c0 12.394043 -10.047363 22.441406 -22.441406 22.441406l-133.35342 0l0 0c-12.394043 0 -22.441406 -10.047363 -22.441406 -22.441406z"
|
||||
fill-rule="nonzero"
|
||||
id="path107" />
|
||||
<path
|
||||
fill="#d9ead3"
|
||||
d="m505.0079 508.6566l0 0c0 -2.2005005 1.783844 -3.9843445 3.9843445 -3.9843445l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173218 1.1669922c0.7472534 0.7471924 1.1669922 1.7606201 1.1669922 2.8173523l0 15.936859c0 2.2004395 -1.7838135 3.984314 -3.984314 3.984314l-117.44867 0l0 0c-2.2005005 0 -3.9843445 -1.7838745 -3.9843445 -3.984314z"
|
||||
fill-rule="nonzero"
|
||||
id="path111" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m505.0079 508.6566l0 0c0 -2.2005005 1.783844 -3.9843445 3.9843445 -3.9843445l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173218 1.1669922c0.7472534 0.7471924 1.1669922 1.7606201 1.1669922 2.8173523l0 15.936859c0 2.2004395 -1.7838135 3.984314 -3.984314 3.984314l-117.44867 0l0 0c-2.2005005 0 -3.9843445 -1.7838745 -3.9843445 -3.984314z"
|
||||
fill-rule="nonzero"
|
||||
id="path113" />
|
||||
<path
|
||||
fill="#d9ead3"
|
||||
d="m506.33215 551.2552l0 0c0 -3.0876465 2.5030212 -5.590637 5.5906677 -5.590637l114.23599 0c1.482727 0 2.9047241 0.58898926 3.953186 1.6374512c1.0484619 1.0484619 1.6374512 2.470459 1.6374512 3.953186l0 22.362c0 3.0876465 -2.5029907 5.590637 -5.590637 5.590637l-114.23599 0c-3.0876465 0 -5.5906677 -2.5029907 -5.5906677 -5.590637z"
|
||||
fill-rule="nonzero"
|
||||
id="path117" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m506.33215 551.2552l0 0c0 -3.0876465 2.5030212 -5.590637 5.5906677 -5.590637l114.23599 0c1.482727 0 2.9047241 0.58898926 3.953186 1.6374512c1.0484619 1.0484619 1.6374512 2.470459 1.6374512 3.953186l0 22.362c0 3.0876465 -2.5029907 5.590637 -5.590637 5.590637l-114.23599 0c-3.0876465 0 -5.5906677 -2.5029907 -5.5906677 -5.590637z"
|
||||
fill-rule="nonzero"
|
||||
id="path119" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m245.26643 311.61713l-152.83566 193.05511"
|
||||
fill-rule="nonzero"
|
||||
id="path125" />
|
||||
<path
|
||||
d="m 156.22123,183.96461 0,0 c 0,-16.76368 11.7863,-30.35331 26.32543,-30.35331 l 125.43956,0 c 6.98195,0 13.67792,3.19792 18.61488,8.89028 4.937,5.69236 7.71055,13.41283 7.71055,21.46303 l 0,121.40961 c 0,16.76365 -11.78631,30.35327 -26.32543,30.35327 l -125.43956,0 c -14.53913,0 -26.32543,-13.58962 -26.32543,-30.35327 z"
|
||||
id="path23"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#f3f3f3;fill-rule:nonzero" />
|
||||
<path
|
||||
fill="#ff9900"
|
||||
stroke="#ff9900"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m97.289154 493.21323l-3.0435638 9.166626l8.223694 -5.065674z"
|
||||
fill-rule="evenodd"
|
||||
id="path129" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m245.26643 311.61713l86.342575 193.05511"
|
||||
fill-rule="nonzero"
|
||||
id="path131" />
|
||||
<path
|
||||
d="m181.9518 204.39761l0 0c0 -2.2004852 1.783844 -3.9843292 3.9843292 -3.9843292l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173218 1.1669769c0.7472229 0.74720764 1.1669922 1.7606506 1.1669922 2.8173523l0 15.936844c0 2.2004852 -1.783844 3.9843445 -3.984314 3.9843445l-117.44867 0l0 0c-2.2004852 0 -3.9843292 -1.7838593 -3.9843292 -3.9843445z"
|
||||
id="path29"
|
||||
fill-rule="nonzero"
|
||||
fill="#d9ead3" />
|
||||
<path
|
||||
fill="#ff9900"
|
||||
stroke="#ff9900"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m323.69415 495.06662l6.721161 6.9365845l-0.6899414 -9.634003z"
|
||||
fill-rule="evenodd"
|
||||
id="path135" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m245.26643 311.61713l322.45013 193.05511"
|
||||
fill-rule="nonzero"
|
||||
id="path137" />
|
||||
<path
|
||||
d="m181.9518 204.39761l0 0c0 -2.2004852 1.783844 -3.9843292 3.9843292 -3.9843292l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173218 1.1669769c0.7472229 0.74720764 1.1669922 1.7606506 1.1669922 2.8173523l0 15.936844c0 2.2004852 -1.783844 3.9843445 -3.984314 3.9843445l-117.44867 0l0 0c-2.2004852 0 -3.9843292 -1.7838593 -3.9843292 -3.9843445z"
|
||||
id="path31"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
stroke-width="2.0"
|
||||
stroke="#000000"
|
||||
fill-rule="nonzero" />
|
||||
<path
|
||||
stroke="#4a86e8"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m464.6291 311.17792l-125.81958 224.02386"
|
||||
fill-rule="evenodd"
|
||||
id="path151" />
|
||||
<path
|
||||
fill="#ff9900"
|
||||
stroke="#ff9900"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m555.7239 501.34235l9.484131 1.8279724l-6.090271 -7.496582z"
|
||||
fill-rule="evenodd"
|
||||
id="path141" />
|
||||
<path
|
||||
stroke="#4a86e8"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m464.6291 311.17792l99.53046 223.52429"
|
||||
fill-rule="evenodd"
|
||||
id="path157" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m464.62912 311.17792l-370.8741 235.69238"
|
||||
fill-rule="nonzero"
|
||||
id="path143" />
|
||||
<path
|
||||
d="m183.06488 241.41388l0 0c0 -2.2004852 1.783844 -3.9843292 3.9843292 -3.9843292l117.448654 0c1.0567322 0 2.07016 0.4197693 2.8173523 1.1669769c0.7472229 0.74720764 1.1669922 1.7606354 1.1669922 2.8173523l0 15.936859c0 2.20047 -1.783844 3.984314 -3.9843445 3.984314l-117.448654 0l0 0c-2.2004852 0 -3.9843292 -1.783844 -3.9843292 -3.984314z"
|
||||
id="path57"
|
||||
fill-rule="nonzero"
|
||||
fill="#d9ead3" />
|
||||
<path
|
||||
d="m 375.26603,165.808 0,0 c 0,-8.38921 11.99571,-15.19001 26.79313,-15.19001 l 125.13991,0 c 7.10597,0 13.92091,1.60037 18.94561,4.44905 5.0247,2.84867 7.8475,6.71232 7.8475,10.74096 l 0,60.75824 c 0,8.38922 -11.99565,15.19002 -26.79311,15.19002 l -125.13991,0 c -14.79742,0 -26.79313,-6.8008 -26.79313,-15.19002 z"
|
||||
id="path37"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none" />
|
||||
<path
|
||||
fill="#4a86e8"
|
||||
stroke="#4a86e8"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m102.111046 537.6459l-5.8883743 7.656189l9.43206 -2.080017z"
|
||||
fill-rule="evenodd"
|
||||
id="path147" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m464.62912 311.17792l-131.69586 234.48663"
|
||||
fill-rule="nonzero"
|
||||
id="path149" />
|
||||
<path
|
||||
d="m183.06488 241.41388l0 0c0 -2.2004852 1.783844 -3.9843292 3.9843292 -3.9843292l117.448654 0c1.0567322 0 2.07016 0.4197693 2.8173523 1.1669769c0.7472229 0.74720764 1.1669922 1.7606354 1.1669922 2.8173523l0 15.936859c0 2.20047 -1.783844 3.984314 -3.9843445 3.984314l-117.448654 0l0 0c-2.2004852 0 -3.9843292 -1.783844 -3.9843292 -3.984314z"
|
||||
id="path59"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
stroke-width="2.0"
|
||||
stroke="#000000"
|
||||
fill-rule="nonzero" />
|
||||
<path
|
||||
fill="#4a86e8"
|
||||
stroke="#4a86e8"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m335.92923 533.5841l-1.564209 9.531189l7.324768 -6.2958374z"
|
||||
fill-rule="evenodd"
|
||||
id="path153" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:28px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="464.71082"
|
||||
y="179.81885"
|
||||
id="text3180"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3182"
|
||||
x="464.71082"
|
||||
y="179.81885"
|
||||
style="font-size:22px">Orchestration</tspan></text>
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m464.62912 311.17792l104.41171 234.48663"
|
||||
fill-rule="nonzero"
|
||||
id="path155" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="465.36441"
|
||||
y="220.22458"
|
||||
id="text3196"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
x="465.36441"
|
||||
y="220.22458"
|
||||
id="tspan3954">MCollective</tspan></text>
|
||||
<path
|
||||
fill="#4a86e8"
|
||||
stroke="#4a86e8"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m561.1417 536.04596l6.709778 6.947571l-0.67419434 -9.635132z"
|
||||
fill-rule="evenodd"
|
||||
id="path159" />
|
||||
<path
|
||||
fill="#fce5cd"
|
||||
d="m96.7496 11.117161l0 0c0 -3.305077 2.6792908 -5.984371 5.9843674 -5.984371l500.1887 0c1.5871582 0 3.109314 0.6304941 4.2316284 1.7527819c1.1222534 1.1222868 1.7527466 2.644436 1.7527466 4.2315893l0 23.936768c0 3.3050766 -2.6792603 5.984371 -5.984375 5.984371l-500.1887 0c-3.3050766 0 -5.9843674 -2.6792946 -5.9843674 -5.984371z"
|
||||
fill-rule="nonzero"
|
||||
id="path161" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m352.82834 41.0383l-107.561905 112.50009"
|
||||
fill-rule="nonzero"
|
||||
id="path167" />
|
||||
<path
|
||||
stroke="#ff9900"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
stroke-dasharray="8.0,6.0"
|
||||
d="m352.82834 41.0383l-99.26912 103.826584"
|
||||
fill-rule="evenodd"
|
||||
id="path169" />
|
||||
<path
|
||||
d="m 156.22123,183.96461 0,0 c 0,-16.76368 11.7863,-30.35331 26.32543,-30.35331 l 125.43956,0 c 6.98195,0 13.67792,3.19792 18.61488,8.89028 4.937,5.69236 7.71055,13.41283 7.71055,21.46303 l 0,121.40961 c 0,16.76365 -11.78631,30.35327 -26.32543,30.35327 l -125.43956,0 c -14.53913,0 -26.32543,-13.58962 -26.32543,-30.35327 z"
|
||||
id="path25"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none" />
|
||||
<path
|
||||
fill="#ff9900"
|
||||
stroke="#ff9900"
|
||||
stroke-width="2.0"
|
||||
stroke-linecap="butt"
|
||||
d="m251.17151 142.58199l-3.8845215 8.843109l8.659958 -4.277298z"
|
||||
fill-rule="evenodd"
|
||||
id="path171" />
|
||||
<path
|
||||
fill="#000000"
|
||||
fill-opacity="0.0"
|
||||
d="m352.82834 41.0383l111.80078 109.82466"
|
||||
fill-rule="nonzero"
|
||||
id="path173" />
|
||||
<path
|
||||
d="m352.82834 41.0383l103.24014 101.415375"
|
||||
id="path175"
|
||||
stroke-dasharray="8.0,6.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
stroke-width="2.0"
|
||||
stroke="#4a86e8"
|
||||
fill-rule="evenodd" />
|
||||
<path
|
||||
stroke="#000000"
|
||||
stroke-width="2.0"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
d="m96.7496 11.117161l0 0c0 -3.305077 2.6792908 -5.984371 5.9843674 -5.984371l500.1887 0c1.5871582 0 3.109314 0.6304941 4.2316284 1.7527819c1.1222534 1.1222868 1.7527466 2.644436 1.7527466 4.2315893l0 23.936768c0 3.3050766 -2.6792603 5.984371 -5.984375 5.984371l-500.1887 0c-3.3050766 0 -5.9843674 -2.6792946 -5.9843674 -5.984371z"
|
||||
fill-rule="nonzero"
|
||||
id="path163" />
|
||||
<path
|
||||
d="m453.7535 144.81032l8.789795 4.003723l-4.1598206 -8.716995z"
|
||||
id="path177"
|
||||
stroke-linecap="butt"
|
||||
stroke-width="2.0"
|
||||
stroke="#4a86e8"
|
||||
fill-rule="evenodd"
|
||||
fill="#4a86e8" />
|
||||
<path
|
||||
d="m181.9518 278.69995l0 0c0 -2.20047 1.783844 -3.984314 3.9843292 -3.984314l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173218 1.1669922c0.7472229 0.7471924 1.1669922 1.7606201 1.1669922 2.8173218l0 15.936859c0 2.2005005 -1.783844 3.9843445 -3.984314 3.9843445l-117.44867 0l0 0c-2.2004852 0 -3.9843292 -1.783844 -3.9843292 -3.9843445z"
|
||||
id="path179"
|
||||
fill-rule="nonzero"
|
||||
fill="#d9ead3" />
|
||||
<path
|
||||
d="m181.9518 278.69995l0 0c0 -2.20047 1.783844 -3.984314 3.9843292 -3.984314l117.44867 0c1.0567017 0 2.0701294 0.4197693 2.8173218 1.1669922c0.7472229 0.7471924 1.1669922 1.7606201 1.1669922 2.8173218l0 15.936859c0 2.2005005 -1.783844 3.9843445 -3.984314 3.9843445l-117.44867 0l0 0c-2.2004852 0 -3.9843292 -1.783844 -3.9843292 -3.9843445z"
|
||||
id="path181"
|
||||
stroke-linejoin="round"
|
||||
stroke-linecap="butt"
|
||||
stroke-width="2.0"
|
||||
stroke="#000000"
|
||||
fill-rule="nonzero" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20.40438461px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="350.72931"
|
||||
y="27.653543"
|
||||
id="text3166"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3168"
|
||||
x="350.72931"
|
||||
y="27.653543">Configuration of OpenStack deployment (UI or CLI)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:28px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.75423"
|
||||
y="182.43326"
|
||||
id="text3176"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3178"
|
||||
x="245.75423"
|
||||
y="182.43326"
|
||||
style="font-size:22px">Cobbler</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="241.79343"
|
||||
y="218.30296"
|
||||
id="text3184"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3186"
|
||||
x="241.79343"
|
||||
y="218.30296"
|
||||
style="font-size:18px">CentOS 6.4</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="243.75424"
|
||||
y="256.21185"
|
||||
id="text3188"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3190"
|
||||
x="243.75424"
|
||||
y="256.21185">RHEL 6.4</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="244.44704"
|
||||
y="292.77435"
|
||||
id="text3192"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3194"
|
||||
x="244.44704"
|
||||
y="292.77435">RHOS 3.0</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="355.83368"
|
||||
y="415.6123"
|
||||
id="text3200"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3202"
|
||||
x="355.83368"
|
||||
y="415.6123"
|
||||
style="font-size:24px">HA Architecture</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="92.758476"
|
||||
y="485.05084"
|
||||
id="text3204"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3206"
|
||||
x="92.758476"
|
||||
y="485.05084">Controller nodes</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="331.45444"
|
||||
y="485.05084"
|
||||
id="text3208"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3210"
|
||||
x="331.45444"
|
||||
y="485.05084">Compute nodes</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="570.71185"
|
||||
y="485.05084"
|
||||
id="text3212"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3214"
|
||||
x="570.71185"
|
||||
y="485.05084">Storage nodes</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="93.465042"
|
||||
y="522.80298"
|
||||
id="text3216"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3218"
|
||||
x="93.465042"
|
||||
y="522.80298"
|
||||
style="font-size:18px">OS</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:14px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="95.42585"
|
||||
y="558.79028"
|
||||
id="text3220"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3222"
|
||||
x="95.42585"
|
||||
y="558.79028"
|
||||
style="font-size:13px">OpenStack</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="95.42585"
|
||||
y="575.04028"
|
||||
id="tspan3224"
|
||||
style="font-size:13px">Components</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="332.60464"
|
||||
y="521.91125"
|
||||
id="text3216-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3218-7"
|
||||
x="332.60464"
|
||||
y="521.91125"
|
||||
style="font-size:18px">OS</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:14px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="334.56546"
|
||||
y="557.89862"
|
||||
id="text3220-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3222-0"
|
||||
x="334.56546"
|
||||
y="557.89862"
|
||||
style="font-size:13px">OpenStack</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="334.56546"
|
||||
y="574.14862"
|
||||
id="tspan3224-9"
|
||||
style="font-size:13px">Components</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="568.55487"
|
||||
y="521.91125"
|
||||
id="text3216-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3218-8"
|
||||
x="568.55487"
|
||||
y="521.91125"
|
||||
style="font-size:18px">OS</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:14px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="570.51569"
|
||||
y="557.89856"
|
||||
id="text3220-8"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3222-2"
|
||||
x="570.51569"
|
||||
y="557.89856"
|
||||
style="font-size:13px">OpenStack</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="570.51569"
|
||||
y="574.14856"
|
||||
id="tspan3224-4"
|
||||
style="font-size:13px">Components</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:40px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="352.55453"
|
||||
y="112.65466"
|
||||
id="text3172"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3174"
|
||||
x="352.55453"
|
||||
y="112.65466"
|
||||
style="font-size:28px;font-weight:bold;text-align:center;text-anchor:middle;-inkscape-font-specification:Sans Bold">Fuel Master Node</tspan></text>
|
||||
<rect
|
||||
style="fill:#aaeeff;fill-opacity:1;stroke:#000000;stroke-width:1.25394762;stroke-linejoin:round;stroke-opacity:1"
|
||||
id="rect3864"
|
||||
width="47.744926"
|
||||
height="16.249495"
|
||||
x="177.29388"
|
||||
y="312.58945"
|
||||
ry="4.3041816" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="201.26846"
|
||||
y="326.59662"
|
||||
id="text3866"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3868"
|
||||
x="201.26846"
|
||||
y="326.59662">DHCP</tspan></text>
|
||||
<rect
|
||||
style="fill:#aaeeff;fill-opacity:1;stroke:#000000;stroke-width:1.25394762;stroke-linejoin:round;stroke-opacity:1"
|
||||
id="rect3864-1"
|
||||
width="47.744926"
|
||||
height="16.249495"
|
||||
x="264.44659"
|
||||
y="312.58911"
|
||||
ry="4.3041816" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="288.42117"
|
||||
y="326.59628"
|
||||
id="text3866-7"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3868-4"
|
||||
x="288.42117"
|
||||
y="326.59628">TFTP</tspan></text>
|
||||
<path
|
||||
d="m 375.40599,259.47541 0,0 c 0,-8.38921 11.99571,-15.19001 26.79313,-15.19001 l 125.13991,0 c 7.10597,0 13.92091,1.60037 18.94561,4.44905 5.0247,2.84867 7.8475,6.71232 7.8475,10.74096 l 0,60.75824 c 0,8.38922 -11.99565,15.19002 -26.79311,15.19002 l -125.13991,0 c -14.79742,0 -26.79313,-6.8008 -26.79313,-15.19002 z"
|
||||
id="path35-4"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#f3f3f3;fill-rule:nonzero" />
|
||||
<path
|
||||
d="m 401.45444,298.71274 0,0 c 0,-2.20049 1.78384,-3.98433 3.98431,-3.98433 l 117.44864,0 c 1.05677,0 2.07019,0.41977 2.81739,1.16698 0.74719,0.74721 1.16699,1.76063 1.16699,2.81735 l 0,15.93684 c 0,2.20049 -1.78388,3.98435 -3.98438,3.98435 l -117.44864,0 0,0 c -2.20047,0 -3.98431,-1.78386 -3.98431,-3.98435 z"
|
||||
id="path41-8"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#d9ead3;fill-rule:nonzero" />
|
||||
<path
|
||||
d="m 401.45444,298.71274 0,0 c 0,-2.20049 1.78384,-3.98433 3.98431,-3.98433 l 117.44864,0 c 1.05677,0 2.07019,0.41977 2.81739,1.16698 0.74719,0.74721 1.16699,1.76063 1.16699,2.81735 l 0,15.93684 c 0,2.20049 -1.78388,3.98435 -3.98438,3.98435 l -117.44864,0 0,0 c -2.20047,0 -3.98431,-1.78386 -3.98431,-3.98435 z"
|
||||
id="path43-8"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:round" />
|
||||
<path
|
||||
d="m 375.40599,259.47541 0,0 c 0,-8.38921 11.99571,-15.19001 26.79313,-15.19001 l 125.13991,0 c 7.10597,0 13.92091,1.60037 18.94561,4.44905 5.0247,2.84867 7.8475,6.71232 7.8475,10.74096 l 0,60.75824 c 0,8.38922 -11.99565,15.19002 -26.79311,15.19002 l -125.13991,0 c -14.79742,0 -26.79313,-6.8008 -26.79313,-15.19002 z"
|
||||
id="path37-2"
|
||||
inkscape:connector-curvature="0"
|
||||
style="stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:10;stroke-dasharray:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:28px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="464.85077"
|
||||
y="273.48627"
|
||||
id="text3180-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3182-5"
|
||||
x="464.85077"
|
||||
y="273.48627"
|
||||
style="font-size:22px">Puppet Master</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:20px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="465.50439"
|
||||
y="313.892"
|
||||
id="text3196-5"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3198-1"
|
||||
x="465.50439"
|
||||
y="313.892">Manifests</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 39 KiB |
|
|
@ -0,0 +1,296 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
viewBox="0 0 740 400"
|
||||
stroke-miterlimit="10"
|
||||
id="svg2"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
width="100%"
|
||||
height="100%"
|
||||
sodipodi:docname="logical-diagram-compute.svg"
|
||||
style="fill:none;stroke:none">
|
||||
<metadata
|
||||
id="metadata191">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs
|
||||
id="defs189">
|
||||
<clipPath
|
||||
id="p.0-9">
|
||||
<path
|
||||
d="M 0,0 776,0 776,778 0,778 0,0 z"
|
||||
clip-rule="nonzero"
|
||||
id="path5-4"
|
||||
inkscape:connector-curvature="0" />
|
||||
</clipPath>
|
||||
</defs>
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1061"
|
||||
id="namedview187"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.18"
|
||||
inkscape:cx="528.32081"
|
||||
inkscape:cy="94.078434"
|
||||
inkscape:window-x="1362"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="g7-8"
|
||||
showborder="true" />
|
||||
<clipPath
|
||||
id="p.0">
|
||||
<path
|
||||
d="M 0,0 872,0 872,800 0,800 0,0 z"
|
||||
clip-rule="nonzero"
|
||||
id="path5"
|
||||
inkscape:connector-curvature="0" />
|
||||
</clipPath>
|
||||
<g
|
||||
clip-path="url(#p.0)"
|
||||
id="g7"
|
||||
transform="translate(0,-400)">
|
||||
<path
|
||||
d="m 0,0 872.7533,0 0,800.5066 -872.7533,0 z"
|
||||
id="path9"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<path
|
||||
d="M 594.77167,352.29922 461.77954,724.50396"
|
||||
id="path129"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<path
|
||||
d="M 594.77167,400.29922 461.77954,724.50396"
|
||||
id="path135"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<g
|
||||
style="fill:none;stroke:none"
|
||||
clip-path="url(#p.0-9)"
|
||||
id="g7-8"
|
||||
transform="translate(2.17745,91.004219)">
|
||||
<path
|
||||
d="m 0,266 776.6352,0 0,778.0551 -776.6352,0 z"
|
||||
id="path9-8"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<path
|
||||
d="m 210.54047,578.74646 290.77167,-0.44724"
|
||||
id="path147"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134"
|
||||
width="318.8446"
|
||||
height="288.27231"
|
||||
x="11.408236"
|
||||
y="342.09085"
|
||||
ry="37.958794" />
|
||||
<g
|
||||
id="g3962"
|
||||
transform="translate(-20,266)">
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="195.52754"
|
||||
x="80.130028"
|
||||
height="92.147392"
|
||||
width="220.86603"
|
||||
id="rect3904"
|
||||
style="fill:#ffe680;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<a
|
||||
transform="translate(-201.00401,73.627356)"
|
||||
id="a3908">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#aaccff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<a
|
||||
style="fill:#de8787"
|
||||
transform="matrix(-1,0,0,1,582.03983,72.403549)"
|
||||
id="a3908-1">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906-7"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#de8787;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3933"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:40px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
id="tspan3935"
|
||||
sodipodi:role="line">HAProxy</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
id="tspan3939"
|
||||
sodipodi:role="line">E</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937-4"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Sans;-inkscape-font-specification:Sans"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
id="tspan3939-0"
|
||||
sodipodi:role="line">I</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="170.97246"
|
||||
y="389.9534"
|
||||
id="text3975"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977"
|
||||
x="170.97246"
|
||||
y="389.9534"
|
||||
style="font-size:40px">Controller Node</tspan></text>
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-9-2-4"
|
||||
width="313.42935"
|
||||
height="342.34512"
|
||||
x="411.56519"
|
||||
y="346.61057"
|
||||
ry="37.958794" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-9-5"
|
||||
width="313.55569"
|
||||
height="342.40125"
|
||||
x="391.68408"
|
||||
y="326.6055"
|
||||
ry="37.958794" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="547.66711"
|
||||
y="377.82129"
|
||||
id="text3975-4-5"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977-8-1"
|
||||
x="547.66711"
|
||||
y="377.82129"
|
||||
style="font-size:36px">Compute Node(s)</tspan></text>
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="407.18646"
|
||||
x="417.90573"
|
||||
height="62.878319"
|
||||
width="263.63934"
|
||||
id="rect3904-8-7"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="549.38324"
|
||||
y="447.49109"
|
||||
id="text4021-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4023-1"
|
||||
x="549.38324"
|
||||
y="447.49109"
|
||||
style="font-size:32px">nova-compute</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#de8787;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:24, 3;stroke-dashoffset:0"
|
||||
d="m 308.67881,506.10896 109.0335,12.36996"
|
||||
id="path4081"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="489.19104"
|
||||
x="417.83594"
|
||||
height="62.878319"
|
||||
width="263.63934"
|
||||
id="rect3904-8-7-2"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="549.31348"
|
||||
y="525.49567"
|
||||
id="text4021-1-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4023-1-5"
|
||||
x="549.31348"
|
||||
y="525.49567"
|
||||
style="font-size:20px">quantum-openvswitch-agent</tspan></text>
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="574.9295"
|
||||
x="417.88425"
|
||||
height="62.878319"
|
||||
width="263.63934"
|
||||
id="rect3904-8-7-2-5"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="549.36176"
|
||||
y="615.23413"
|
||||
id="text4021-1-4-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4023-1-5-7"
|
||||
x="549.36176"
|
||||
y="615.23413"
|
||||
style="font-size:32px">Open vSwitch</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#de8787;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:24, 3;stroke-dashoffset:0"
|
||||
d="M 310.25495,506.09893 417.16981,437.96042"
|
||||
id="path4081-1"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 12 KiB |
|
|
@ -0,0 +1,891 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="1240"
|
||||
height="1170"
|
||||
id="svg3675"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="logical-diagram-controller.svg">
|
||||
<defs
|
||||
id="defs3677">
|
||||
<inkscape:perspective
|
||||
sodipodi:type="inkscape:persp3d"
|
||||
inkscape:vp_x="0 : 526.18109 : 1"
|
||||
inkscape:vp_y="0 : 1000 : 0"
|
||||
inkscape:vp_z="744.09448 : 526.18109 : 1"
|
||||
inkscape:persp3d-origin="372.04724 : 350.78739 : 1"
|
||||
id="perspective4607" />
|
||||
</defs>
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="0.7"
|
||||
inkscape:cx="748.9681"
|
||||
inkscape:cy="577.55364"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
showgrid="false"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1061"
|
||||
inkscape:window-x="1362"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1" />
|
||||
<metadata
|
||||
id="metadata3680">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(0,117.63782)">
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:5;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134"
|
||||
width="342.05441"
|
||||
height="958.38666"
|
||||
x="75.803215"
|
||||
y="73.368881"
|
||||
ry="37.958794" />
|
||||
<g
|
||||
transform="translate(56.04691,176.22262)"
|
||||
style="fill:none;stroke:none"
|
||||
id="g3962">
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="195.52754"
|
||||
x="80.130028"
|
||||
height="92.147392"
|
||||
width="220.86603"
|
||||
id="rect3904"
|
||||
style="fill:#ffe680;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<a
|
||||
transform="translate(-201.00401,73.627356)"
|
||||
id="a3908">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#aaccff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<a
|
||||
style="fill:#de8787"
|
||||
transform="matrix(-1,0,0,1,582.03983,72.403549)"
|
||||
id="a3908-1">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906-7"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#de8787;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3933"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:40px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
id="tspan3935"
|
||||
sodipodi:role="line">HAProxy</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
id="tspan3939"
|
||||
sodipodi:role="line">E</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937-4"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Sans;-inkscape-font-specification:Sans"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
id="tspan3939-0"
|
||||
sodipodi:role="line">I</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="248.99905"
|
||||
y="129.80286"
|
||||
id="text3975"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977"
|
||||
x="248.99905"
|
||||
y="129.80286"
|
||||
style="font-size:40px">Controller Node 1</tspan></text>
|
||||
<rect
|
||||
style="fill:#e9c6af;fill-opacity:1;stroke:#ffb380;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect3720"
|
||||
width="307.59146"
|
||||
height="199.00005"
|
||||
x="93.238609"
|
||||
y="156.18689"
|
||||
ry="21.395082" />
|
||||
<rect
|
||||
style="fill:#afe9af;fill-opacity:1;stroke:#d3bc5f;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect3722"
|
||||
width="307.08472"
|
||||
height="37.254822"
|
||||
x="93.17997"
|
||||
y="152.89386"
|
||||
ry="18.627411" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="247.07144"
|
||||
y="179.43362"
|
||||
id="text4497"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4499"
|
||||
x="247.07144"
|
||||
y="179.43362"
|
||||
style="font-size:28px">pacemaker</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501"
|
||||
width="237.18752"
|
||||
height="67.678574"
|
||||
x="126.14285"
|
||||
y="205.64789"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="246.07141"
|
||||
y="227.79074"
|
||||
id="text4503"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505"
|
||||
x="246.07141"
|
||||
y="227.79074"
|
||||
style="font-size:28px">quantum agents</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="246.07141"
|
||||
y="262.79074"
|
||||
style="font-size:28px"
|
||||
id="tspan4751">(active)</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.92857"
|
||||
y="288.61218"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.85712"
|
||||
y="320.755"
|
||||
id="text4503-7"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4"
|
||||
x="245.85712"
|
||||
y="320.755"
|
||||
style="font-size:28px">mysql-wsrep</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-9"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.25546"
|
||||
y="480.40936"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.18401"
|
||||
y="512.55219"
|
||||
id="text4503-7-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-8"
|
||||
x="245.18401"
|
||||
y="512.55219"
|
||||
style="font-size:28px">horizon</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-5"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="904.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="936.75513"
|
||||
id="text4503-7-5"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-1"
|
||||
x="245.40793"
|
||||
y="936.75513"
|
||||
style="font-size:28px">cinder-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-7"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="844.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="876.75525"
|
||||
id="text4503-7-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-15"
|
||||
x="245.40793"
|
||||
y="876.75525"
|
||||
style="font-size:28px">quantum-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-2"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="784.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="816.75525"
|
||||
id="text4503-7-7"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-6"
|
||||
x="245.40793"
|
||||
y="816.75525"
|
||||
style="font-size:28px">keystone-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-1"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="722.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="754.75525"
|
||||
id="text4503-7-42"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-3"
|
||||
x="245.40793"
|
||||
y="754.75525"
|
||||
style="font-size:28px">glance-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-22"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="660.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="692.75525"
|
||||
id="text4503-7-16"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-85"
|
||||
x="245.40793"
|
||||
y="692.75525"
|
||||
style="font-size:28px">nova-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-76"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="600.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="632.75525"
|
||||
id="text4503-7-18"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-9"
|
||||
x="245.40793"
|
||||
y="632.75525"
|
||||
style="font-size:28px">nova-scheduler</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-27"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.47938"
|
||||
y="540.61243"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.40793"
|
||||
y="572.75525"
|
||||
id="text4503-7-9"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-5"
|
||||
x="245.40793"
|
||||
y="572.75525"
|
||||
style="font-size:28px">glance-registry</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-5-2"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="125.42857"
|
||||
y="966.505"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="245.35712"
|
||||
y="998.64771"
|
||||
id="text4503-7-5-3"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-1-3"
|
||||
x="245.35712"
|
||||
y="998.64771"
|
||||
style="font-size:28px">rabbitmq</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 363.65237,505.86966 c 103.43913,-9.65095 84.85441,-39.21033 23.2335,-88.89343 55.45253,32.13564 150.5919,99.87426 -23.73858,147.98735"
|
||||
id="path4777"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccc" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 363.65237,623.04735 c 262.25319,-75.69176 83.01391,-188.90098 23.73858,-206.5762 60.30982,14.54186 322.32004,99.75379 -24.24366,267.18535"
|
||||
id="path4779"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccc" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="M 363.65237,748.30627 C 771.33868,546.74035 489.08817,416.27964 386.88587,416.47115 508.58962,403.26064 814.933,552.65391 364.15744,805.88496"
|
||||
id="path4781"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccc" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="M 363.14729,869.52457 C 720.58451,680.28139 703.25667,417.79917 387.39095,416.97623 694.20531,390.26915 794.98682,682.75881 364.15744,929.12357"
|
||||
id="path4783"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccc" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 361.63206,318.99144 c 182.25498,-2.80172 197.04369,64.58407 25.25381,96.97464 555.94787,-17.01765 193.12643,508.23417 -24.02873,563.53896"
|
||||
id="path4785"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccc" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:5;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-4"
|
||||
width="342.05441"
|
||||
height="958.38666"
|
||||
x="871.98938"
|
||||
y="73.29512"
|
||||
ry="37.958794" />
|
||||
<g
|
||||
transform="translate(852.23307,176.14886)"
|
||||
style="fill:none;stroke:none"
|
||||
id="g3962-1">
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="195.52754"
|
||||
x="80.130028"
|
||||
height="92.147392"
|
||||
width="220.86603"
|
||||
id="rect3904-1"
|
||||
style="fill:#ffe680;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<a
|
||||
transform="translate(-201.00401,73.627356)"
|
||||
id="a3908-3"
|
||||
style="fill:#d5e5ff">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906-8"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#d5e5ff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<a
|
||||
style="fill:#f4d7d7"
|
||||
transform="matrix(-1,0,0,1,582.03983,72.403549)"
|
||||
id="a3908-1-7">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906-7-4"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#f4d7d7;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3933-2"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:40px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
id="tspan3935-7"
|
||||
sodipodi:role="line">HAProxy</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937-7"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
id="tspan3939-9"
|
||||
sodipodi:role="line">E</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937-4-3"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Sans;-inkscape-font-specification:Sans"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
id="tspan3939-0-1"
|
||||
sodipodi:role="line">I</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1045.1852"
|
||||
y="129.72908"
|
||||
id="text3975-9"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977-8"
|
||||
x="1045.1852"
|
||||
y="129.72908"
|
||||
style="font-size:40px">Controller Node 2</tspan></text>
|
||||
<rect
|
||||
style="fill:#e9c6af;fill-opacity:1;stroke:#ffb380;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect3720-6"
|
||||
width="307.59146"
|
||||
height="199.00005"
|
||||
x="889.42474"
|
||||
y="156.11311"
|
||||
ry="21.395082" />
|
||||
<rect
|
||||
style="fill:#afe9af;fill-opacity:1;stroke:#d3bc5f;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect3722-5"
|
||||
width="307.08472"
|
||||
height="37.254822"
|
||||
x="889.36615"
|
||||
y="152.82008"
|
||||
ry="18.627411" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1043.2576"
|
||||
y="179.35985"
|
||||
id="text4497-0"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4499-2"
|
||||
x="1043.2576"
|
||||
y="179.35985"
|
||||
style="font-size:28px">pacemaker</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-8"
|
||||
width="237.18752"
|
||||
height="67.678574"
|
||||
x="922.32898"
|
||||
y="205.57411"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1042.2576"
|
||||
y="227.71696"
|
||||
id="text4503-6"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-0"
|
||||
x="1042.2576"
|
||||
y="227.71696"
|
||||
style="font-size:28px">quantum agents</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="1042.2576"
|
||||
y="262.71698"
|
||||
style="font-size:28px"
|
||||
id="tspan4751-2">(hot standby)</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-4"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="922.11475"
|
||||
y="288.53842"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1042.0432"
|
||||
y="320.68124"
|
||||
id="text4503-7-8"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-65"
|
||||
x="1042.0432"
|
||||
y="320.68124"
|
||||
style="font-size:28px">mysql-wsrep</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-9-0"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.44159"
|
||||
y="480.33557"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.3701"
|
||||
y="512.47839"
|
||||
id="text4503-7-4-9"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-8-0"
|
||||
x="1041.3701"
|
||||
y="512.47839"
|
||||
style="font-size:28px">horizon</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-5-0"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="904.5387"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="936.6814"
|
||||
id="text4503-7-5-6"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-1-1"
|
||||
x="1041.5941"
|
||||
y="936.6814"
|
||||
style="font-size:28px">cinder-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-7-3"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="844.53864"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="876.68146"
|
||||
id="text4503-7-1-8"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-15-9"
|
||||
x="1041.5941"
|
||||
y="876.68146"
|
||||
style="font-size:28px">quantum-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-2-3"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="784.53864"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="816.68146"
|
||||
id="text4503-7-7-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-6-4"
|
||||
x="1041.5941"
|
||||
y="816.68146"
|
||||
style="font-size:28px">keystone-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-1-6"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="722.53864"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="754.68146"
|
||||
id="text4503-7-42-0"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-3-6"
|
||||
x="1041.5941"
|
||||
y="754.68146"
|
||||
style="font-size:28px">glance-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-22-6"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="660.53864"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="692.68146"
|
||||
id="text4503-7-16-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-85-8"
|
||||
x="1041.5941"
|
||||
y="692.68146"
|
||||
style="font-size:28px">nova-api</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-76-4"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="600.53864"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="632.68146"
|
||||
id="text4503-7-18-9"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-9-6"
|
||||
x="1041.5941"
|
||||
y="632.68146"
|
||||
style="font-size:28px">nova-scheduler</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-27-3"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.66553"
|
||||
y="540.53864"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5941"
|
||||
y="572.68146"
|
||||
id="text4503-7-9-7"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-5-8"
|
||||
x="1041.5941"
|
||||
y="572.68146"
|
||||
style="font-size:28px">glance-registry</tspan></text>
|
||||
<rect
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#999999;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none;stroke-dashoffset:0"
|
||||
id="rect4501-1-5-2-8"
|
||||
width="237.14287"
|
||||
height="45.357143"
|
||||
x="921.61475"
|
||||
y="966.43115"
|
||||
ry="8.3928566" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="1041.5432"
|
||||
y="998.57385"
|
||||
id="text4503-7-5-3-2"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4505-4-1-3-9"
|
||||
x="1041.5432"
|
||||
y="998.57385"
|
||||
style="font-size:28px">rabbitmq</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 920.35714,317.71932 -531.78571,98.21429 532.14286,88.57143"
|
||||
id="path4963"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="ccc" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 920,564.50504 -533.57143,-150 L 920,621.6479"
|
||||
id="path4965"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 921.42857,684.50504 -534.28571,-270 L 920,748.07647"
|
||||
id="path4967"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="M 920,810.93361 388.57143,416.6479 920.71429,869.50504"
|
||||
id="path4969"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#4d4d4d;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="M 920,928.07647 387.85714,415.93361 921.42857,979.50504"
|
||||
id="path4971"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#808080;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="m 363.57143,990.04108 556.78571,-6.5e-4"
|
||||
id="path4973"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#808080;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:36, 3;stroke-dashoffset:0"
|
||||
d="M 364.46429,302.79108 921.25,302.79043"
|
||||
id="path4973-9"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="640.61438"
|
||||
y="295.75793"
|
||||
id="text5104"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan5106"
|
||||
x="640.61438"
|
||||
y="295.75793"
|
||||
style="font-size:24px">MySQL Galera Cluster</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="640.61438"
|
||||
y="325.75793"
|
||||
id="tspan5108"
|
||||
style="font-size:24px">(Active/Active)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="638.4519"
|
||||
y="983.6109"
|
||||
id="text5110"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan5112"
|
||||
x="638.4519"
|
||||
y="983.6109"
|
||||
style="font-size:24px">RabbitMQ Cluster</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="638.4519"
|
||||
y="1013.6109"
|
||||
id="tspan5114"
|
||||
style="font-size:24px">(Active/Active)</tspan></text>
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path27"
|
||||
d="m 558.316,-23.660493 c -0.59251,-2.74117 -0.59251,-4.9341 -0.59251,-7.12704 0,-15.350561 13.03515,-27.411714 29.62534,-27.411714 9.48011,0 18.36771,4.385873 23.70027,10.964684 9.48011,-25.767009 36.14291,-44.406974 67.54577,-44.406974 39.10544,0 71.10081,29.056416 71.10081,65.788114 0,2.19293 -0.59251,4.38587 -0.59251,7.12704 0.59251,0 1.77752,0 2.96253,0 24.29278,0 44.43801,18.09172968 44.43801,41.11757 0,22.477599 -20.14523,41.117569 -44.43801,41.117569 -0.5925,0 -185.45461,0 -185.45461,0 -26.6628,-0.54824 -47.40054,-20.28467 -47.40054,-43.858739 0,-21.9293703 16.59019,-40.0211 39.10545,-43.31051 l 0,0"
|
||||
style="fill:#d5e5ff;stroke:#000000;stroke-width:5;stroke-miterlimit:4;stroke-dasharray:none" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:5;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
d="M 520,3.7907535 C -220.16235,-149.5968 65.153465,421.66824 104.28571,420.93362"
|
||||
id="path6237"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="654.85712"
|
||||
y="18.076468"
|
||||
id="text6239"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan6241"
|
||||
x="654.85712"
|
||||
y="18.076468"
|
||||
style="font-size:32px">External VIP</tspan></text>
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path27-4"
|
||||
d="m 435.31601,404.48236 c -0.59251,-2.74117 -0.59251,-4.93409 -0.59251,-7.12703 0,-15.35056 13.03515,-27.41172 29.62534,-27.41172 9.48011,0 18.36771,4.38588 23.70027,10.96469 9.48011,-25.76701 36.14291,-44.40698 67.54577,-44.40698 39.10544,0 71.10081,29.05642 71.10081,65.78811 0,2.19293 -0.59251,4.38587 -0.59251,7.12704 0.59251,0 1.77752,0 2.96253,0 24.29278,0 44.43801,18.09173 44.43801,41.11757 0,22.4776 -20.14523,41.11757 -44.43801,41.11757 -0.5925,0 -185.45461,0 -185.45461,0 -26.6628,-0.54824 -47.40054,-20.28467 -47.40054,-43.85874 0,-21.92937 16.59019,-40.0211 39.10545,-43.31051 l 0,0"
|
||||
style="fill:#f4d7d7;fill-opacity:0.80882353;stroke:#000000;stroke-width:5;stroke-miterlimit:4;stroke-dasharray:none;marker-end:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="531.85712"
|
||||
y="446.21933"
|
||||
id="text6239-7"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan6241-8"
|
||||
x="531.85712"
|
||||
y="446.21933"
|
||||
style="font-size:32px">Internal VIP</tspan></text>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 39 KiB |
|
|
@ -0,0 +1,277 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
version="1.1"
|
||||
viewBox="0 0 776 470"
|
||||
stroke-miterlimit="10"
|
||||
id="svg2"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
width="100%"
|
||||
height="100%"
|
||||
sodipodi:docname="050-logical-diagram-storage.svg"
|
||||
style="fill:none;stroke:none">
|
||||
<metadata
|
||||
id="metadata157">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<defs
|
||||
id="defs155" />
|
||||
<sodipodi:namedview
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1"
|
||||
objecttolerance="10"
|
||||
gridtolerance="10"
|
||||
guidetolerance="10"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1061"
|
||||
id="namedview153"
|
||||
showgrid="false"
|
||||
inkscape:snap-object-midpoints="true"
|
||||
inkscape:zoom="0.85798046"
|
||||
inkscape:cx="444.85891"
|
||||
inkscape:cy="475.70368"
|
||||
inkscape:window-x="1362"
|
||||
inkscape:window-y="-4"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="svg2" />
|
||||
<clipPath
|
||||
id="p.0">
|
||||
<path
|
||||
d="M 0,0 776,0 776,778 0,778 0,0 z"
|
||||
clip-rule="nonzero"
|
||||
id="path5"
|
||||
inkscape:connector-curvature="0" />
|
||||
</clipPath>
|
||||
<g
|
||||
clip-path="url(#p.0)"
|
||||
id="g7"
|
||||
transform="translate(0,9.02354)">
|
||||
<path
|
||||
d="m 0,0 776.6352,0 0,778.0551 -776.6352,0 z"
|
||||
id="path9"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-9-2"
|
||||
width="315.548"
|
||||
height="170.41849"
|
||||
x="415.74762"
|
||||
y="30.979057"
|
||||
ry="37.958794" />
|
||||
<path
|
||||
d="m 230.54047,312.74646 290.77167,-0.44724"
|
||||
id="path147"
|
||||
inkscape:connector-curvature="0"
|
||||
style="fill:#000000;fill-opacity:0;fill-rule:nonzero" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134"
|
||||
width="318.8446"
|
||||
height="288.27231"
|
||||
x="31.408236"
|
||||
y="76.090836"
|
||||
ry="37.958794" />
|
||||
<g
|
||||
id="g3962">
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="195.52754"
|
||||
x="80.130028"
|
||||
height="92.147392"
|
||||
width="220.86603"
|
||||
id="rect3904"
|
||||
style="fill:#ffe680;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<a
|
||||
transform="translate(-201.00401,73.627356)"
|
||||
id="a3908">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#aaccff;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<a
|
||||
style="fill:#de8787"
|
||||
transform="matrix(-1,0,0,1,582.03983,72.403549)"
|
||||
id="a3908-1">
|
||||
<path
|
||||
sodipodi:nodetypes="cccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="rect3906-7"
|
||||
d="m 252.28936,144.794 39.05743,-0.11735 19.08248,23.45486 -19.08248,24.00726 -39.05743,0.11736 z"
|
||||
style="fill:#de8787;fill-opacity:1;stroke:#000000;stroke-width:2;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
</a>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3933"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:40px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="256.01593"
|
||||
x="189.72931"
|
||||
id="tspan3935"
|
||||
sodipodi:role="line">HAProxy</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-weight:normal;-inkscape-font-specification:Sans"
|
||||
y="254.02962"
|
||||
x="73.931664"
|
||||
id="tspan3939"
|
||||
sodipodi:role="line">E</tspan></text>
|
||||
<text
|
||||
sodipodi:linespacing="125%"
|
||||
id="text3937-4"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
xml:space="preserve"><tspan
|
||||
style="font-size:32px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Sans;-inkscape-font-specification:Sans"
|
||||
y="252.10518"
|
||||
x="306.31552"
|
||||
id="tspan3939-0"
|
||||
sodipodi:role="line">I</tspan></text>
|
||||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="190.97246"
|
||||
y="123.95339"
|
||||
id="text3975"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977"
|
||||
x="190.97246"
|
||||
y="123.95339"
|
||||
style="font-size:40px">Controller Node</tspan></text>
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-9"
|
||||
width="315.548"
|
||||
height="170.41849"
|
||||
x="405.94635"
|
||||
y="21.518507"
|
||||
ry="37.958794" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="565.51056"
|
||||
y="69.381065"
|
||||
id="text3975-4"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977-8"
|
||||
x="565.51056"
|
||||
y="69.381065"
|
||||
style="font-size:40px">Swift Nodes</tspan></text>
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="102.74622"
|
||||
x="453.74918"
|
||||
height="63.302048"
|
||||
width="221.69019"
|
||||
id="rect3904-8"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="565.22668"
|
||||
y="147.05086"
|
||||
id="text4021"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4023"
|
||||
x="565.22668"
|
||||
y="147.05086"
|
||||
style="font-size:40px">swift</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#ff6600;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:24, 3;stroke-dashoffset:0"
|
||||
d="m 677.1716,128.65538 c 110.87082,-2.76813 47.64094,20.83381 47.64094,20.83381"
|
||||
id="path4043"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-9-2-4"
|
||||
width="315.548"
|
||||
height="170.41849"
|
||||
x="415.90417"
|
||||
y="265.41931"
|
||||
ry="37.958794" />
|
||||
<rect
|
||||
style="fill:#f2f2f2;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="rect3134-9-5"
|
||||
width="315.548"
|
||||
height="170.41849"
|
||||
x="406.10291"
|
||||
y="255.95874"
|
||||
ry="37.958794" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="565.66711"
|
||||
y="303.82129"
|
||||
id="text3975-4-5"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan3977-8-1"
|
||||
x="565.66711"
|
||||
y="303.82129"
|
||||
style="font-size:40px">Swift Proxies</tspan></text>
|
||||
<rect
|
||||
ry="17.772001"
|
||||
y="337.18646"
|
||||
x="453.90573"
|
||||
height="63.302048"
|
||||
width="221.69019"
|
||||
id="rect3904-8-7"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:none" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:normal;text-align:center;line-height:125%;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans"
|
||||
x="565.38324"
|
||||
y="381.49109"
|
||||
id="text4021-1"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4023-1"
|
||||
x="565.38324"
|
||||
y="381.49109"
|
||||
style="font-size:40px">swift-proxy</tspan></text>
|
||||
<path
|
||||
style="fill:none;stroke:#de8787;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:24, 3;stroke-dashoffset:0"
|
||||
d="M 328.67881,240.10896 453.39028,363.07214"
|
||||
id="path4081"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#d3bc5f;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10;stroke-opacity:1;stroke-dasharray:24, 3;stroke-dashoffset:0"
|
||||
d="m 574.73185,167.52254 -0.17371,168.14203"
|
||||
id="path4081-1"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 52 KiB |
|
|
@ -0,0 +1,71 @@
|
|||
#!/bin/bash
|
||||
|
||||
# Copyright 2013 Mirantis, Inc.
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
||||
# not use this file except in compliance with the License. You may obtain
|
||||
# a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
# License for the specific language governing permissions and limitations
|
||||
# under the License.
|
||||
|
||||
# The number of nodes for installing OpenStack on
|
||||
# - for minimal non-HA installation, specify 2 (1 controller + 1 compute)
|
||||
# - for minimal non-HA with Cinder installation, specify 3 (1 ctrl + 1 compute + 1 cinder)
|
||||
# - for minimal HA installation, specify 4 (3 controllers + 1 compute)
|
||||
cluster_size=3
|
||||
|
||||
# Get the first available ISO from the directory 'iso'
|
||||
iso_path=`ls -1 iso/*.iso 2>/dev/null | head -1`
|
||||
|
||||
# Every Fuel Web machine name will start from this prefix
|
||||
vm_name_prefix=fuel-web-
|
||||
|
||||
# Host interfaces to bridge VMs interfaces with
|
||||
idx=0
|
||||
for ip in 10.20.0.1 172.16.1.1 172.16.0.1; do
|
||||
host_nic_name[$idx]=vboxnet$idx
|
||||
host_nic_ip[$idx]=$ip
|
||||
host_nic_mask[$idx]=255.255.255.0
|
||||
idx=$((idx+1))
|
||||
done
|
||||
|
||||
# Master node settings
|
||||
vm_master_cpu_cores=1
|
||||
vm_master_memory_mb=1024
|
||||
vm_master_disk_mb=16384
|
||||
|
||||
# Master node access to the internet through the host system, using VirtualBox NAT adapter
|
||||
vm_master_nat_network=192.168.200/24
|
||||
vm_master_nat_gateway=192.168.200.2
|
||||
|
||||
# These settings will be used to check if master node has installed or not.
|
||||
# If you modify networking params for master node during the boot time
|
||||
# (i.e. if you pressed Tab in a boot loader and modified params),
|
||||
# make sure that these values reflect that change.
|
||||
vm_master_ip=10.20.0.2
|
||||
vm_master_username=root
|
||||
vm_master_password=r00tme
|
||||
vm_master_prompt='root@fuel ~]#'
|
||||
|
||||
# Slave node settings
|
||||
vm_slave_cpu_cores=1
|
||||
|
||||
# This section allows you to define RAM size in MB for each slave node.
|
||||
# Keep in mind that PXE boot might not work correctly with values lower than 768.
|
||||
# You can specify memory size for the specific slaves, other will get default vm_slave_memory_default
|
||||
vm_slave_memory_default=768
|
||||
vm_slave_memory_mb[1]=768 # for controller node 768 MB should be sufficient
|
||||
vm_slave_memory_mb[2]=1024 # for compute node 1GB is recommended, otherwise VM instances in OpenStack may not boot
|
||||
vm_slave_memory_mb[3]=768 # for a dedicated Cinder node 768 MB should be sufficient
|
||||
|
||||
# This section allows you to define HDD size in MB for all the slaves nodes.
|
||||
# All the slaves will have identical disk configuration. Each slave will have three disks of the following sizes.
|
||||
vm_slave_first_disk_mb=16384
|
||||
vm_slave_second_disk_mb=32768
|
||||
vm_slave_third_disk_mb=65536
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 7.3 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 1.1 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 3.0 KiB |
10
conf.py
10
conf.py
|
|
@ -74,7 +74,7 @@ release = '3.1'
|
|||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
exclude_patterns = ['_build']
|
||||
exclude_patterns = ['_*', "pages"]
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all documents.
|
||||
#default_role = None
|
||||
|
|
@ -128,7 +128,7 @@ html_logo = '_static/fuel_gradient_200.png'
|
|||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
html_favicon = None
|
||||
html_favicon = '_static/mirantis_icon.ico'
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
|
|
@ -137,7 +137,7 @@ html_static_path = ['_static']
|
|||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
html_last_updated_fmt = '%b %d, %Y'
|
||||
html_last_updated_fmt = '%c, %Z'
|
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||
# typographically correct entities.
|
||||
|
|
@ -159,7 +159,7 @@ html_sidebars = {
|
|||
html_use_index = True
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
html_split_index = False
|
||||
html_split_index = True
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
html_show_sourcelink = False
|
||||
|
|
@ -179,7 +179,7 @@ html_show_copyright = True
|
|||
#html_file_suffix = None
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'fuel'
|
||||
htmlhelp_basename = 'fueldoc'
|
||||
|
||||
|
||||
# -- Options for LaTeX output --------------------------------------------------
|
||||
|
|
|
|||
22
contents.rst
22
contents.rst
|
|
@ -1,16 +1,20 @@
|
|||
.. index:: Table of Contents
|
||||
|
||||
.. _ToC:
|
||||
|
||||
=================
|
||||
Table of Contents
|
||||
=================
|
||||
|
||||
.. toctree:: Table of Contents
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
index
|
||||
pages/0010-package-contents
|
||||
pages/0020-about-fuel
|
||||
pages/0030-release-notes
|
||||
pages/0040-reference-architecture
|
||||
pages/0045-installation-fuel-web
|
||||
pages/0050-installation-instructions
|
||||
pages/0055-production-considerations
|
||||
pages/0060-frequently-asked-questions
|
||||
0020-about-fuel
|
||||
0030-release-notes
|
||||
0040-reference-architecture
|
||||
0055-production-considerations
|
||||
0045-installation-fuel-ui
|
||||
0050-installation-fuel-cli
|
||||
0060-frequently-asked-questions
|
||||
copyright
|
||||
|
|
|
|||
|
|
@ -1,6 +1,8 @@
|
|||
.. index:: license
|
||||
.. index:: License
|
||||
|
||||
============
|
||||
Fuel License
|
||||
============
|
||||
|
||||
.. literalinclude:: LICENSE
|
||||
:language: none
|
||||
88
index.rst
88
index.rst
|
|
@ -1,22 +1,28 @@
|
|||
Introduction to Fuel for OpenStack
|
||||
==================================
|
||||
.. index:: Introduction
|
||||
|
||||
OpenStack is an extensible, versatile, and flexible cloud management platform.
|
||||
By exposing its portfolio of cloud infrastructure services – compute, storage,
|
||||
networking and other core resources — through ReST APIs, OpenStack enables a
|
||||
wide range of control over these services, both from the perspective of an
|
||||
integrated Infrastructure as a Service (IaaS) controlled by applications, as
|
||||
well as automated manipulation of the infrastructure itself.
|
||||
.. _Introduction:
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically. It asks you, the
|
||||
user and cloud administrator, to organize and manage an extensive array of
|
||||
configuration options. Consequently, getting the most out of your OpenStack
|
||||
cloud over time – in terms of flexibility, scalability, and manageability –
|
||||
requires a thoughtful combination of complex configuration choices. This can be
|
||||
very time consuming and requires a significant amount of studious documentation
|
||||
to comprehend.
|
||||
===============================
|
||||
Introducing Fuel™ for OpenStack
|
||||
===============================
|
||||
|
||||
Mirantis Fuel for OpenStack was created to eliminate exactly these problems.
|
||||
OpenStack is an extensible, versatile, and flexible cloud management
|
||||
platform. By exposing its portfolio of cloud infrastructure services –
|
||||
compute, storage, networking and other core resources — through ReST APIs,
|
||||
OpenStack enables a wide range of control over these services, both from the
|
||||
perspective of an integrated Infrastructure as a Service (IaaS) controlled
|
||||
by applications, as well as automated manipulation of the infrastructure
|
||||
itself.
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically. It asks you,
|
||||
the user and cloud administrator, to organize and manage an extensive array
|
||||
of configuration options. Consequently, getting the most out of your
|
||||
OpenStack cloud over time – in terms of flexibility, scalability, and
|
||||
manageability – requires a thoughtful combination of complex configuration
|
||||
choices. This can be very time consuming and requires a significant amount
|
||||
of studious documentation to comprehend.
|
||||
|
||||
Mirantis Fuel™ for OpenStack was created to eliminate exactly these problems.
|
||||
This step-by-step guide takes you through this process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud
|
||||
|
|
@ -26,50 +32,52 @@ This step-by-step guide takes you through this process of:
|
|||
* Providing access to a well-integrated, up-to-date set of components known to
|
||||
work together
|
||||
|
||||
Fuel™ for OpenStack can be used to create virtually any OpenStack configuration.
|
||||
To make things easier, the installation includes several pre-defined
|
||||
architectures. For the sake of simplicity, this guide emphasises a single,
|
||||
common reference architecture; the multi-node, high-availability configuration.
|
||||
We begin with an explanation of this architecture, then move on to the details
|
||||
of creating the configuration in a test environment using VirtualBox. Finally,
|
||||
we give you the information you need to know to create this and other OpenStack
|
||||
architectures in a production environment.
|
||||
Fuel™ for OpenStack can be used to create virtually any OpenStack
|
||||
configuration. To make things easier, the installation includes several
|
||||
pre-defined architectures. For the sake of simplicity, this guide emphasises
|
||||
a single, common reference architecture; the multi-node, high-availability
|
||||
configuration. We begin with an explanation of this architecture, then move
|
||||
on to the details of creating the configuration in a test environment using
|
||||
VirtualBox. Finally, we give you the information you need to know to create
|
||||
this and other OpenStack architectures in a production environment.
|
||||
|
||||
This guide assumes that you are familiar with general Linux commands and
|
||||
administration concepts, as well as general networking concepts. You should have
|
||||
some familiarity with grid or virtualization systems such as Amazon Web Services
|
||||
or VMware, as well as OpenStack itself, but you don't need to be an expert.
|
||||
administration concepts, as well as general networking concepts. You should
|
||||
have some familiarity with grid or virtualization systems such as Amazon Web
|
||||
Services or VMware, as well as OpenStack itself, but you don't need to be an
|
||||
expert.
|
||||
|
||||
The Fuel User Guide is organized as follows:
|
||||
|
||||
* :ref:`About Fuel <About_Fuel>`, gives you an
|
||||
* :ref:`About_Fuel`, gives you an
|
||||
overview of Fuel and gives you a general idea of how it works.
|
||||
|
||||
* :ref:`Reference Architecture <Reference-Architecture>`, provides a
|
||||
* :ref:`Reference-Architectures`, provides a
|
||||
general look at the components that make up OpenStack.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel Web <Fuel-Web-Cluster>`,
|
||||
* :ref:`Create-Cluster-UI`,
|
||||
takes you step-by-step through the process of creating a high-availability
|
||||
OpenStack cluster using Fuel Web.
|
||||
OpenStack cluster using Fuel UI.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel <Create-Cluster>`,
|
||||
* :ref:`Deploy-Cluster-CLI`,
|
||||
takes you step-by-step through the more advanced process of creating a
|
||||
high-availability OpenStack cluster using the standard Fuel tools.
|
||||
high-availability OpenStack cluster using the command line and Puppet
|
||||
manifests.
|
||||
|
||||
* :ref:`Production Considerations <Production>`, looks at the
|
||||
* :ref:`Production`, looks at the
|
||||
real-world questions and problems involved in creating an OpenStack cluster
|
||||
for production use. We discuss issues such as network layout and hardware
|
||||
requirements, and provide tips and tricks for creating a cluster of up to 100
|
||||
nodes.
|
||||
|
||||
* With the current (3.1) release Fuel and FuelWeb has been integrated. We encourage all
|
||||
users to use the Fuel Web process for installation and configuration. However,
|
||||
the standard Fuel installation process is still available for those of you who
|
||||
* With the current (3.1) release Fuel UI (aka FuelWeb) and Fuel CLI
|
||||
(aka Fuel Library) are integrated. We encourage all users to use the Fuel
|
||||
UI for installation and configuration. However,
|
||||
the standard Fuel CLI installation process is still available for those who
|
||||
prefer a more detailed approach to deployment. Even with a utility as powerful
|
||||
as Fuel, creating an OpenStack cluster can be complex, and
|
||||
:ref:`Frequently Asked Questions <FAQ>`, covers many of the issues that tend
|
||||
to arise during the process.
|
||||
:ref:`FAQ` covers many of the issues that tend to arise during the process.
|
||||
|
||||
Lets start off by taking a look at Fuel itself. We'll start by explaining what
|
||||
it is and :ref:`how Fuel works <How-Fuel-Works>` , and then move to the process
|
||||
it is and :ref:`How-Fuel-Works`, and then move to the process
|
||||
of installation itself.
|
||||
|
|
|
|||
|
|
@ -1,53 +0,0 @@
|
|||
Introduction to Fuel for OpenStack
|
||||
==================================
|
||||
|
||||
.. This guide explains how to use Fuel to easily create and maintain an OpenStack
|
||||
cloud infrastructure.
|
||||
|
||||
Fuel™ for OpenStack can be used to create virtually any OpenStack configuration.
|
||||
To make things easier, the installation includes several pre-defined
|
||||
architectures. For the sake of simplicity, this guide emphasises a single,
|
||||
common reference architecture; the multi-node, high-availability configuration.
|
||||
We begin with an explanation of this architecture, then move on to the details
|
||||
of creating the configuration in a test environment using VirtualBox. Finally,
|
||||
we give you the information you need to know to create this and other OpenStack
|
||||
architectures in a production environment.
|
||||
|
||||
This guide assumes that you are familiar with general Linux commands and
|
||||
administration concepts, as well as general networking concepts. You should have
|
||||
some familiarity with grid or virtualization systems such as Amazon Web Services
|
||||
or VMware, as well as OpenStack itself, but you don't need to be an expert.
|
||||
|
||||
The Fuel User Guide is organized as follows:
|
||||
|
||||
* :ref:`About Fuel <About_Fuel>`, gives you an
|
||||
overview of Fuel and gives you a general idea of how it works.
|
||||
|
||||
* :ref:`Reference Architecture <Reference-Architecture>`, provides a
|
||||
general look at the components that make up OpenStack.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel Web <Fuel-Web-Cluster>`,
|
||||
takes you step-by-step through the process of creating a high-availability
|
||||
OpenStack cluster using Fuel Web.
|
||||
|
||||
* :ref:`Create a multi-node OpenStack cluster using Fuel <Create-Cluster>`,
|
||||
takes you step-by-step through the more advanced process of creating a
|
||||
high-availability OpenStack cluster using the standard Fuel tools.
|
||||
|
||||
* :ref:`Production Considerations <Production>`, looks at the
|
||||
real-world questions and problems involved in creating an OpenStack cluster
|
||||
for production use. We discuss issues such as network layout and hardware
|
||||
requirements, and provide tips and tricks for creating a cluster of up to 100
|
||||
nodes.
|
||||
|
||||
* With the current (3.1) release Fuel and FuelWeb has been integrated. We encourage all
|
||||
users to use the Fuel Web process for installation and configuration. However,
|
||||
the standard Fuel installation process is still available for those of you who
|
||||
prefer a more detailed approach to deployment. Even with a utility as powerful
|
||||
as Fuel, creating an OpenStack cluster can be complex, and
|
||||
:ref:`Frequently Asked Questions <FAQ>`, covers many of the issues that tend
|
||||
to arise during the process.
|
||||
|
||||
Lets start off by taking a look at Fuel itself. We'll start by explaining what
|
||||
it is and :ref:`how Fuel works <How-Fuel-Works>` , and then move to the process
|
||||
of installation itself.
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
Preface
|
||||
=======
|
||||
|
||||
OpenStack is an extensible, versatile, and flexible cloud management platform.
|
||||
By exposing its portfolio of cloud infrastructure services – compute, storage,
|
||||
networking and other core resources — through ReST APIs, OpenStack enables a
|
||||
wide range of control over these services, both from the perspective of an
|
||||
integrated Infrastructure as a Service (IaaS) controlled by applications, as
|
||||
well as automated manipulation of the infrastructure itself.
|
||||
|
||||
This architectural flexibility doesn’t set itself up magically. It asks you, the
|
||||
user and cloud administrator, to organize and manage an extensive array of
|
||||
configuration options. Consequently, getting the most out of your OpenStack
|
||||
cloud over time – in terms of flexibility, scalability, and manageability –
|
||||
requires a thoughtful combination of complex configuration choices. This can be
|
||||
very time consuming and requires a significant amount of studious documentation
|
||||
to comprehend.
|
||||
|
||||
Mirantis Fuel for OpenStack was created to eliminate exactly these problems.
|
||||
This step-by-step guide takes you through this process of:
|
||||
|
||||
* Configuring OpenStack and its supporting components into a robust cloud
|
||||
architecture
|
||||
* Deploying that architecture through an effective, well-integrated automation
|
||||
package that sets up and maintains the components and their configurations
|
||||
* Providing access to a well-integrated, up-to-date set of components known to
|
||||
work together
|
||||
|
|
@ -1,9 +0,0 @@
|
|||
Release Notes
|
||||
-------------
|
||||
|
||||
.. include:: /pages/release-notes/v3-1-grizzly.rst
|
||||
.. include:: /pages/release-notes/v3-0-grizzly.rst
|
||||
.. include:: /pages/release-notes/v2-1-folsom.rst
|
||||
.. include:: /pages/release-notes/v2-0-folsom.rst
|
||||
.. include:: /pages/release-notes/v1-0-essex.rst
|
||||
|
||||
|
|
@ -1,8 +0,0 @@
|
|||
.. _Fuel-Web-Cluster:
|
||||
|
||||
Create a multi-node OpenStack cluster using FuelWeb
|
||||
====================================================
|
||||
|
||||
.. include:: /pages/installation-fuel-web/install.rst
|
||||
.. include:: /pages/installation-fuel-web/networks.rst
|
||||
.. include:: /pages/installation-fuel-web/network-issues.rst
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
.. _Create-Cluster:
|
||||
|
||||
Create a multi-node OpenStack cluster using Fuel
|
||||
================================================
|
||||
|
||||
.. _contents:: :local:
|
||||
|
||||
.. _include:: /pages/installation-instructions/0000-preamble.rst
|
||||
.. _include:: /pages/installation-instructions/0010-introduction.rst
|
||||
.. _include:: /pages/installation-instructions/0015-before-you-start.rst
|
||||
.. _include:: /pages/installation-instructions/0020-machines.rst
|
||||
.. _include:: /pages/installation-instructions/0057-prepare-for-deployment.rst
|
||||
.. include:: /pages/installation-instructions/0060-understand-the-manifest.rst
|
||||
.. include:: /pages/installation-instructions/0070-orchestration.rst
|
||||
.. include:: /pages/installation-instructions/0080-testing-openstack.rst
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
.. _Create-PM:
|
||||
|
||||
Appendix A: Creating Fuel-pm from scratch
|
||||
==========================================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. include:: /pages/creating-fuel-pm/0010-creating-fuel-pm-from-scratch.rst
|
||||
.. include:: /pages/creating-fuel-pm/0045-configuring-fuel-pm.rst
|
||||
.. include:: /pages/creating-fuel-pm/0050-installing-configuring-cobbler.rst
|
||||
.. include:: /pages/creating-fuel-pm/0060-register-with-fuel.rst
|
||||
|
|
@ -1,9 +1,14 @@
|
|||
What is Fuel?
|
||||
-----------------
|
||||
.. index:: What is Fuel?
|
||||
|
||||
Fuel is a ready-to-install collection of the packages and scripts you need to
|
||||
create a robust, configurable, vendor-independant OpenStack cloud in your own
|
||||
environment.
|
||||
.. _What_is_Fuel:
|
||||
|
||||
What is Fuel?
|
||||
=============
|
||||
|
||||
Fuel is a ready-to-install collection of the packages and scripts you need
|
||||
to create a robust, configurable, vendor-independent OpenStack cloud in your
|
||||
own environment. As of Fuel 3.1, Fuel Library and Fuel Web have been merged
|
||||
into a single toolbox with options to use the UI or CLI for management.
|
||||
|
||||
A single OpenStack cloud consists of packages from many different open source
|
||||
projects, each with its own requirements, installation procedures, and
|
||||
|
|
@ -15,5 +20,7 @@ through a single installation.
|
|||
Simply put, Fuel is a way for you to easily configure and install an
|
||||
OpenStack-based infrastructure in your own environment.
|
||||
|
||||
.. image:: /_images/FuelSimpleDiagramv.png
|
||||
:width: 100%
|
||||
.. fancybox:: /_images/FuelSimpleDiagramv.png
|
||||
:width: 400px
|
||||
:height: 400px
|
||||
|
||||
|
|
|
|||
|
|
@ -1,41 +1,37 @@
|
|||
.. index: How Fuel Works
|
||||
|
||||
.. _How-Fuel-Works:
|
||||
|
||||
How Fuel Works
|
||||
--------------
|
||||
==============
|
||||
|
||||
Fuel works on a simple premise. Rather than installing each of the myriad
|
||||
Fuel works on a simple premise. Rather than installing each of the
|
||||
components that make up OpenStack directly, you instead use a configuration
|
||||
management system like Puppet to create scripts that can provide a configurable,
|
||||
reproducible, sharable installation process.
|
||||
management system like Puppet to create scripts that can provide a
|
||||
configurable, reproducible, sharable installation process.
|
||||
|
||||
In practice, that means that the process of using Fuel Library looks like this:
|
||||
In practice, that means that the process of using Fuel looks like 1-2-3:
|
||||
|
||||
#. First, use Fuel's automation tools and instructions to set up a master
|
||||
node with Puppet Master and Cobbler. This process only needs to be
|
||||
completed once per installation.
|
||||
1. First, set up Fuel Master Node using the ISO. This process only needs to be
|
||||
completed once per installation.
|
||||
|
||||
#. Next, use Fuel's snippets, kickstart files, and preseed files for Cobbler
|
||||
to boot the appropriate servers from bare metal and automatically install
|
||||
the appropriate operating systems. These virtual or physical servers boot
|
||||
up already prepared to call on the Puppet Master to receive their
|
||||
respective OpenStack components.
|
||||
2. Next, discover your virtual or phisical nodes and configure your OpenStack
|
||||
cluster using the Fuel UI.
|
||||
|
||||
#. Finally, to complete the basic OpenStack install, use Fuel's puppet
|
||||
manifests to install OpenStack on the newly created servers. These
|
||||
manifests are completely customizable, enabling you to start with one of
|
||||
the included OpenStack architectures and adapt to your own situation as
|
||||
necessary.
|
||||
3. Finally, deploy your OpenStack cluster on discovered nodes. Fuel will do all
|
||||
deployment magic for you by applying pre-configured Puppet manifests.
|
||||
|
||||
.. image:: /_images/010-how-it-works_svg.png
|
||||
:width: 100%
|
||||
All of this is desgined to enable you to maintain your cluster while giving
|
||||
you the flexibility to adapt it to your own configuration.
|
||||
|
||||
Fuel comes with several pre-defined deployment configurations, some of which
|
||||
include additional options from which you can choose.
|
||||
.. fancybox:: /_images/010-how-it-works_svg.png
|
||||
:width: 400px
|
||||
:height: 400px
|
||||
|
||||
As of the 3.1 release of Fuel for OpenStack, FuelWeb is included as part of the
|
||||
package. FuelWeb is a simplified way to deploy production-grade OpenStack
|
||||
clouds. FuelWeb provides a streamlined, graphical console experience using the
|
||||
underlying scripts from Fuel Library, including proven deployment configurations
|
||||
and a well-organized workflow for deploying and managing OpenStack environments.
|
||||
Fuel comes with several pre-defined deployment configurations, some of them
|
||||
include additional configuration options that allow you to adapt OpenStack
|
||||
deployment to your environment.
|
||||
|
||||
FuelWeb integrates all of the components of Fuel Library into a unified,
|
||||
web-based graphical user interface that walks administrators through the process
|
||||
of installing and configuring a fully functional OpenStack environment.
|
||||
Fuel UI integrates all of the deployments scripts into a unified,
|
||||
web-based graphical user interface that walks administrators through the
|
||||
process of installing and configuring a fully functional OpenStack environment.
|
||||
|
|
|
|||
|
|
@ -1,22 +1,37 @@
|
|||
.. index:: Deployment Configurations
|
||||
|
||||
.. _Deployment_Configurations:
|
||||
|
||||
Deployment Configurations Provided By Fuel
|
||||
------------------------------------------
|
||||
==========================================
|
||||
|
||||
One of the advantages of Fuel is that it comes with a number of pre-built deployment configurations that you can use to quickly build your own OpenStack cloud infrastructure. These are well-specified configurations of OpenStack and its constituent components are tailored to one or more common cloud use cases. Fuel provides the ability to create the following cluster types without requiring extensive customization:
|
||||
One of the advantages of Fuel is that it comes with a number of pre-built
|
||||
deployment configurations that you can use to quickly build your own
|
||||
OpenStack cloud infrastructure. These are well-specified configurations of
|
||||
OpenStack and its constituent components that are expertly tailored to one
|
||||
or more common cloud use cases. Fuel provides the ability to create the
|
||||
following cluster types without requiring extensive customization:
|
||||
|
||||
**Single node**: Perfect for getting a feel for how OpenStack works, the Single-node installation is the simplest way to get OpenStack up and running. The Single-node installation provides an easy way to install an entire OpenStack cluster on a single physical server system or in a virtual machine environment.
|
||||
**Simple (non-HA)**: The Simple (non-HA) installation provides an easy way
|
||||
to install an entire OpenStack cluster without requiring the degree of
|
||||
increased hardware involved in ensuring high availability.
|
||||
|
||||
**Multi-node (non-HA)**: The Multi-node (non-HA) installation enables you to try out additional OpenStack services like Cinder, Neutron (formerly Quantum), and Swift without requiring the degree of increased hardware involved in ensuring high availability. In addition to the ability to independently specify which services to activate, you also have the following options:
|
||||
**Multi-node (HA)**: When you're ready to begin your move to production, the
|
||||
Multi-node (HA) configuration is a straightforward way to create an OpenStack
|
||||
cluster that provides high availability. With three controller nodes and the
|
||||
ability to individually specify services such as Cinder, Neutron (formerly
|
||||
Quantum), and Swift, Fuel provides the following variations of the
|
||||
Multi-node (HA) configurations:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on your controllers, reducing your hardware requirements by eliminating the need for additional Swift servers.
|
||||
**Compact HA**: When you choose this option, Swift will be installed on
|
||||
your controllers, reducing your hardware requirements by eliminating the need
|
||||
for additional Swift servers while still addressing high availability
|
||||
requirements.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift nodes, so that you can separate their operation from your controller nodes.
|
||||
**Full HA**: This option enables you to install independent Swift and Proxy
|
||||
nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Multi-node (HA)**: When you're ready to begin your move to production, the Multi-node (HA) configuration is a straightforward way to create an OpenStack cluster that provides high availability. With three controller nodes and the ability to individually specify services such as Cinder, Neutron, and Swift, Fuel provides the following variations of the Multi-node (HA) configuration:
|
||||
|
||||
**Compact Swift**: When you choose this option, Swift will be installed on your controllers, reducing your hardware requirements by eliminating the need for additional Swift servers while still addressing high availability requirements.
|
||||
|
||||
**Standalone Swift**: This option enables you to install independant Swift nodes, so that you can separate their operation from your controller nodes.
|
||||
|
||||
**Compact Neutron**: If you don't need the flexibility of a separate Neutron node, Fuel provides the option to combine your Neutron node with one of your controllers.
|
||||
|
||||
In addition to these configurations, Fuel is designed to be completely customizable. For assistance on deeper customization options based on the included configurations you can `contact Mirantis for further assistance <http://www.mirantis.com/contact/>`_.
|
||||
In addition to these configurations, Fuel is designed to be completely
|
||||
customizable. For assistance on deeper customization options based on the
|
||||
included configurations you can `contact Mirantis for further assistance
|
||||
<http://www.mirantis.com/contact/>`_.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
Supported Software
|
||||
------------------
|
||||
.. index: Supported Software; Components
|
||||
|
||||
Fuel has been tested and is guaranteed to work with the following software components:
|
||||
Supported Software
|
||||
==================
|
||||
|
||||
Fuel has been tested and is guaranteed to work with the following software
|
||||
components:
|
||||
|
||||
* Operating Systems
|
||||
* CentOS 6.4 (x86_64 architecture only)
|
||||
|
|
|
|||
|
|
@ -1,11 +1,14 @@
|
|||
Download Fuel
|
||||
-------------
|
||||
.. index: Download Fuel
|
||||
|
||||
The first step in installing Fuel is to download the version appropriate for
|
||||
Download Fuel
|
||||
=============
|
||||
|
||||
The first step in installing Fuel is to download the version appropriate to
|
||||
your environment.
|
||||
|
||||
Fuel is available for Essex, Folsom and Grizzly OpenStack installations, and
|
||||
will be available for Havana shortly after Havana's release.
|
||||
|
||||
The master node ISO, along with other Fuel releases, is available in the
|
||||
`Downloads <http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel portal.
|
||||
The Fuel ISO and IMG, along with other Fuel releases, are available in the
|
||||
`Downloads <http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel
|
||||
portal.
|
||||
|
|
|
|||
|
|
@ -1,23 +1,43 @@
|
|||
RabbitMQ Cluster Restart Issues Following A Systemwide Failure
|
||||
--------------------------------------------------------------
|
||||
==============================================================
|
||||
|
||||
**Issue:**
|
||||
As a rule of thumb, all RabbitMQ nodes must not be shut down simultaneously. RabbitMQ requires that after a full shutdown of the cluster, the first node brought up should be the last one to shut down, but it's not always possible to know which node that is in the event of a power outage or similar event. Versions 2.1 and later of Fuel solve this problem by managing the restart of available nodes, so you should not experience difficulty with this issue.
|
||||
**Issue:** As a rule of thumb, all RabbitMQ nodes must not be shut down
|
||||
simultaneously. RabbitMQ requires that after a full shutdown of the cluster,
|
||||
the first node brought up should be the last one to shut down, but it's not
|
||||
always possible to know which node that is in the event of a power outage or
|
||||
similar event. Fuel solve this problem by
|
||||
managing the restart of available nodes, so you should not experience
|
||||
difficulty with this issue.
|
||||
|
||||
If you are still using previous versions of Fuel, the following describes how Fuel 2.1 works around this problem which, in turn, you can use to perform the steps manually.
|
||||
If you are still using previous versions of Fuel, the following describes
|
||||
how Fuel works around this problem which, in turn, you can use to
|
||||
perform the steps manually.
|
||||
|
||||
**Workaround:**
|
||||
There are 2 possible scenarios, depending on the results of the shutdown:
|
||||
|
||||
#. The RabbitMQ master node is alive and can be started.
|
||||
#. It's impossible to start the RabbitMQ master node due to a hardware or system failure
|
||||
1. The RabbitMQ master node is alive and can be started.
|
||||
2. It's impossible to start the RabbitMQ master node due to a hardware or system failure
|
||||
|
||||
Fuel 2.1 updates the ``/etc/init.d/rabbitmq-server`` init scripts for RHEL/Centos and Ubuntu to customized versions. These scripts attempt to start RabbitMQ twice, giving the RabbitMQ master node the necessary time to start after complete power loss. With the scripts in place, power up all nodes, then check to see whether the RabbitMQ server started on all nodes. All nodes should start automatically.
|
||||
Fuel updates the ``/etc/init.d/rabbitmq-server`` init scripts for
|
||||
RHEL/Centos to customized versions. These scripts attempt to
|
||||
start RabbitMQ twice, giving the RabbitMQ master node the necessary time to
|
||||
start after complete power loss. With the scripts in place, power up all
|
||||
nodes, then check to see whether the RabbitMQ server started on all nodes.
|
||||
All nodes should start automatically.
|
||||
|
||||
On the other hand, if the RabbitMQ master node has failed, the init script performs the following actions during the rabbitmq-server start. It moves the existing Mnesia database to a backup directory, and then makes the third and final attempt to start the RabbitMQ server. In this case, RabbitMQ starts with a clean database, and the live rabbit nodes assemble a new cluster. The script uses the current RabbitMQ settings to find the current Mnesia location and creates a backup directory in the same path as Mnesia, tagged with the current date.
|
||||
|
||||
So with the customized init scripts included in Fuel 2.1, in most cases RabbitMQ simply starts after complete power loss and automatically assembles the cluster, but you can manage the process yourself.
|
||||
On the other hand, if the RabbitMQ master node has failed, the init script
|
||||
performs the following actions during the rabbitmq-server start. It moves
|
||||
the existing Mnesia database to a backup directory, and then makes the third
|
||||
and final attempt to start the RabbitMQ server. In this case, RabbitMQ
|
||||
starts with a clean database, and the live rabbit nodes assemble a new
|
||||
cluster. The script uses the current RabbitMQ settings to find the current
|
||||
Mnesia location and creates a backup directory in the same path as Mnesia,
|
||||
tagged with the current date.
|
||||
|
||||
So with the customized init scripts included in Fuel, in most cases
|
||||
RabbitMQ simply starts after complete power loss and automatically assembles
|
||||
the cluster, but you can manage the process yourself.
|
||||
|
||||
**Background:** See http://comments.gmane.org/gmane.comp.networking.rabbitmq.general/19792.
|
||||
|
||||
|
|
@ -53,5 +73,3 @@ So with the customized init scripts included in Fuel 2.1, in most cases RabbitMQ
|
|||
.. _Enabling Stored Configuration: http://fuel.mirantis.com/reference-documentation-on-fuel-folsom/installing-configuring-puppet-master-2/#puppet-master-stored-config
|
||||
.. _http://openlife.cc/blogs/2011/july/ultimate-mysql-high-availability-solution: http://openlife.cc/blogs/2011/july/ultimate-mysql-high-availability-solution
|
||||
.. _http://www.google.com: http://www.google.com/
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,48 +1,94 @@
|
|||
.. This is not ready for inclusion into docs
|
||||
|
||||
.. _add-remove-nodes-without-downtime:
|
||||
|
||||
Add or Remove Controller and Compute Nodes Without Downtime
|
||||
-----------------------------------------------------------
|
||||
===========================================================
|
||||
|
||||
1. Addition of computes works seamlessly - just specify its IPs in site.pp (if needed) and run puppet
|
||||
2. Deletion of computes is the same as deletion from openstack: migrate machines, shutdown node, delete from database (Puppet class needed)
|
||||
3. Addition of controllers works as soon as puppet deploys. Which testing is needed:
|
||||
a. Test that altering the site.pp (adding new controller) and running puppet consequently on all controllers does not break anything
|
||||
4. Deletion of controllers should work as soon as quorum for galera and pacemaker is OK. What to test:
|
||||
a. Altering of quorum in case of node deletion
|
||||
b. If we need to alter quorum - we need to write classes for this
|
||||
This document will assist you in understanding certain concepts and
|
||||
processes around the management of controller and compute nodes within an
|
||||
OpenStack cluster. There are some specific details to note, making this
|
||||
document required reading.
|
||||
|
||||
1. The addition of compute nodes works seamlessly - just specify its
|
||||
IPs in `site.pp` file (if needed) and run puppet agent
|
||||
|
||||
2. Deletion of computes is the same as deletion from OpenStack: migrate
|
||||
machines, shutdown node, delete from database (Puppet class needed)
|
||||
|
||||
3. Addition of controllers works as soon as puppet deploys. Which
|
||||
testing is needed:
|
||||
|
||||
- Test that altering the `site.pp` (adding new controller) and
|
||||
running puppet consequently on all controllers does not break anything
|
||||
|
||||
4. Deletion of controllers should work as soon as quorum for Galera and
|
||||
pacemaker is OK. What to test:
|
||||
|
||||
- Altering of quorum in case of node deletion
|
||||
- If we need to alter quorum - we need to write classes for this
|
||||
|
||||
Node deletion
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Disclaimer: BTW, this is not included into folsom as cinder service disabling is not supported: it is going to be there in grizzly. Even though, cinder deletion and migration of volumes is not going to be there. Artem Andreev says, they are working on cinder volume migration for Dell M2 and it will be ready by the end of the May.
|
||||
Disclaimer: BTW, this is not included into folsom as cinder service
|
||||
disabling is not supported: it is going to be there in grizzly. Even
|
||||
though, cinder deletion and migration of volumes is not going to be there.
|
||||
Artem Andreev says, they are working on cinder volume migration for Dell M2
|
||||
and it will be ready by the end of the May.
|
||||
|
||||
Deletion of the node assumes the following sequence of actions:
|
||||
|
||||
1. Back databases (MySQL, AMQP(???), pacemaker) up
|
||||
1. Backup databases (MySQL, AMQP(???), pacemaker) up
|
||||
|
||||
2. Disable services hosted on this node:
|
||||
|
||||
a. shutdown nova-compute and disable it (for computes)
|
||||
|
||||
b. shutdown nova-api and other services residing on controllers
|
||||
|
||||
c. move all the stuff from node being deleted:
|
||||
|
||||
i. migrate VMS
|
||||
|
||||
ii. migrate cinder volumes (HOW?????)
|
||||
|
||||
iii. migrate singleton pacemaker services (if any)
|
||||
iv. avoid starting of pacemaker services on the node in case of multistate primitive
|
||||
d. Disable all the services for the node (by use of database or by use of client)
|
||||
|
||||
iv. avoid starting of pacemaker services on the node in case of
|
||||
multistate primitive
|
||||
|
||||
d. Disable all the services for the node (by use of database or by use
|
||||
of client)
|
||||
|
||||
3. For controllers:
|
||||
|
||||
a. Delete node from galera cluster (HOW???)
|
||||
|
||||
b. Delete node from pacemaker (crm node delete ???)
|
||||
|
||||
4. For swift storages:
|
||||
|
||||
a. remove node from the ring (for storage)
|
||||
|
||||
b. rebuild ring
|
||||
|
||||
c. rebalance
|
||||
|
||||
d. rsync new rings to nodes
|
||||
|
||||
5. For swift proxies:
|
||||
|
||||
a. shutdown the node
|
||||
|
||||
b. update haproxy backends by site.pp edit and puppet run
|
||||
|
||||
6. Cleanup the database
|
||||
|
||||
Necessity of special resources considerations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Looks like we need to create special puppet resource called "node" with different providers "controller/storage/proxy/etc." for it and specify the :ensure property for them. Running the resource with corresponding property generates corresponding resources and does all the steps needed.
|
||||
Looks like we need to create special puppet resource called "node" with
|
||||
different providers "controller/storage/proxy/etc." for it and specify the
|
||||
:ensure property for them. Running the resource with corresponding property
|
||||
generates corresponding resources and does all the steps needed.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,27 @@
|
|||
Corosync crashes without network
|
||||
================================
|
||||
|
||||
Depending on a wide range of systems and configurations in network it is
|
||||
possible for Corosync's networking protocol, TOTEM, to time out. If this
|
||||
happens for an extended period of time, Corosync may crash. In addition,
|
||||
MySQL may have stopped. This guide illustrates the process of working
|
||||
through Corosync and Corosync with MySQL issues.
|
||||
|
||||
**Workaround:**
|
||||
|
||||
1. Verify that corosync is really broken ``service corosync status``.
|
||||
|
||||
* You should see next error: ``corosync dead but pid file exists``
|
||||
|
||||
2. Start corosync manually ``service corosync start``.
|
||||
|
||||
3. Run ``ps -ef | grep mysql`` and kill ALL(!) **mysqld** and
|
||||
**mysqld_safe** processes.
|
||||
|
||||
4. Wait while pacemaker starts mysql processes again.
|
||||
|
||||
* You can check it with ``ps -ef | grep mysql`` command.
|
||||
* If it doesn't start, run ``crm resource p_mysql`` start.
|
||||
|
||||
5. Check with ``crm status`` command that this host is part of the cluster
|
||||
and p_mysql is not within "Failed actions".
|
||||
|
|
@ -3,14 +3,16 @@
|
|||
Common Technical Issues
|
||||
-----------------------
|
||||
|
||||
1. Puppet fails with ::
|
||||
1. Puppet fails with::
|
||||
|
||||
err: Could not retrieve catalog from remote server: Error 400 on SERVER: undefined method 'fact_merge' for nil:NilClass"
|
||||
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
|
||||
undefined method 'fact_merge' for nil:NilClass"
|
||||
|
||||
* This is a Puppet bug. See: http://projects.puppetlabs.com/issues/3234
|
||||
* Workaround: ``service puppetmaster restart``
|
||||
|
||||
2. Puppet client will never resend the certificate to Puppet Master. The certificate cannot be signed and verified.
|
||||
2. Puppet client will never resend the certificate to Puppet Master. The
|
||||
certificate cannot be signed and verified.
|
||||
|
||||
* This is a Puppet bug. See: http://projects.puppetlabs.com/issues/4680
|
||||
* Workaround:
|
||||
|
|
@ -23,12 +25,15 @@ Common Technical Issues
|
|||
|
||||
rm -f /var/lib/puppet/ssl/ca/requests/\*.pem
|
||||
|
||||
#. The manifests are up-to-date under ``/etc/puppet/manifests``, but Puppet master keeps serving the previous version of manifests to the clients. Manifests seem to be cached by the Puppet Master.
|
||||
3. The manifests are up-to-date under ``/etc/puppet/manifests``, but Puppet
|
||||
Master keeps serving the previous version of manifests to the clients.
|
||||
Manifests seem to be cached by the Puppet Master.
|
||||
|
||||
* More information: https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/OpCBjV1nR2M
|
||||
* Workaround: ``service puppetmaster restart``
|
||||
|
||||
#. Timeout error for fuel-controller-XX when running ``puppet-agent --test`` to install OpenStack when using HDD instead of SSD ::
|
||||
4. Timeout error for fuel-controller-XX when running ``puppet-agent --test`` to
|
||||
install OpenStack when using HDD instead of SSD ::
|
||||
|
||||
| Sep 26 17:56:15 fuel-controller-02 puppet-agent[1493]: Could not retrieve catalog from remote server: execution expired
|
||||
| Sep 26 17:56:15 fuel-controller-02 puppet-agent[1493]: Not using cache on failed catalog
|
||||
|
|
@ -37,7 +42,7 @@ Common Technical Issues
|
|||
* Workaround: ``vi /etc/puppet/puppet.conf``
|
||||
* add: ``configtimeout = 1200``
|
||||
|
||||
#. On running "``puppet agent --test``", the error messages below occur::
|
||||
5. On running "``puppet agent --test``", the error messages below occur::
|
||||
|
||||
| err: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve information from environment production source(s) puppet://fuel-pm.localdomain/plugins
|
||||
|
||||
|
|
@ -51,49 +56,33 @@ Common Technical Issues
|
|||
|
||||
* Workaround: The second problem can be solved by rebooting Puppet master.
|
||||
|
||||
#. PuppetDB Connection Failures:
|
||||
|
||||
Puppet fails on fuel-pm with message::
|
||||
|
||||
Could not retrieve catalog from remote server: Error 400 on SERVER: Failed to submit 'replace facts' command for fuel-pm to PuppetDB at fuel-pm:8081: Connection refused - connect(2)
|
||||
|
||||
This message is often the result of one of the following:
|
||||
|
||||
* Firewall blocking the puppetdb port
|
||||
* DNS issues with the hostname specified in your puppetdb.conf
|
||||
* DNS issues with the ssl-host specified in your jetty.ini on the puppetdb server
|
||||
|
||||
* Workaround: If you are able to connect (e.g. via telnet) to port 8081 on the puppetdb machine, puppetdb is running. To try and isolate the problem, add the following to ``/etc/puppetdb/conf.d/jetty.ini``::
|
||||
|
||||
certificate-whitelist = /etc/puppetdb/whitelist.txt
|
||||
|
||||
Be sure to list all aliases for the machine in that file.
|
||||
|
||||
.. _create-the-XFS-partition:
|
||||
|
||||
Creating the XFS partition
|
||||
--------------------------
|
||||
|
||||
In most cases, Fuel creates the XFS partition for you. If for some reason you need to create it yourself, use this procedure:
|
||||
In most cases, Fuel creates the XFS partition for you. If for some reason you
|
||||
need to create it yourself, use this procedure:
|
||||
|
||||
#. Create the partition itself::
|
||||
1. Create the partition itself::
|
||||
|
||||
fdisk /dev/sdb
|
||||
n(for new)
|
||||
p(for partition)
|
||||
<enter> (to accept the defaults)
|
||||
<enter> (to accept the defaults)
|
||||
w(to save changes)
|
||||
n(for new)
|
||||
p(for partition)
|
||||
<enter> (to accept the defaults)
|
||||
<enter> (to accept the defaults)
|
||||
w(to save changes)
|
||||
|
||||
#. Initialize the XFS partition::
|
||||
2. Initialize the XFS partition::
|
||||
|
||||
mkfs.xfs -i size=1024 -f /dev/sdb1
|
||||
|
||||
#. For a standard swift install, all data drives are mounted directly under /srv/node, so first create the mount point::
|
||||
3. For a standard swift install, all data drives are mounted directly under
|
||||
/srv/node, so first create the mount point::
|
||||
|
||||
mkdir -p /srv/node/sdb1
|
||||
|
||||
#. Finally, add the new partition to fstab so it mounts automatically, then mount all current partitions::
|
||||
4. Finally, add the new partition to fstab so it mounts automatically, then mount all current partitions::
|
||||
|
||||
echo "/dev/sdb1 /srv/node/sdb1 xfs
|
||||
noatime,nodiratime,nobarrier,logbufs=8 0 0" >> /etc/fstab
|
||||
|
|
@ -102,8 +91,12 @@ In most cases, Fuel creates the XFS partition for you. If for some reason you n
|
|||
Redeploying a node from scratch
|
||||
-------------------------------
|
||||
|
||||
Compute and Cinder nodes in an HA configuration and controller in any configuration cannot be redeployed without completely redeploying the cluster. However, in a non-HA situation you can redeploy a compute or Cinder node. To do so, follow these steps:
|
||||
Compute and Cinder nodes in an HA configuration and controller in any
|
||||
configuration cannot be redeployed without completely redeploying the cluster.
|
||||
However, in a non-HA situation you can redeploy a compute or Cinder node.
|
||||
To do so, follow these steps:
|
||||
|
||||
#. Remove the certificate for the node by executing the command ``puppet cert clean <hostname>`` on fuel-pm.
|
||||
#. Re-boot the node over the network so it can be picked up by cobbler.
|
||||
#. Run the puppet agent on the target node using ``puppet agent --test``.
|
||||
1. Remove the certificate for the node by executing the command
|
||||
``puppet cert clean <hostname>`` on fuel-pm.
|
||||
2. Re-boot the node over the network so it can be picked up by cobbler.
|
||||
3. Run the puppet agent on the target node using ``puppet agent --test``.
|
||||
|
|
|
|||
|
|
@ -1,8 +1,21 @@
|
|||
Other Questions
|
||||
---------------
|
||||
|
||||
#. **[Q]** Why did you decide to provide OpenStack packages through your own repository?
|
||||
1. **[Q]** Why did you decide to provide OpenStack packages through your own
|
||||
repository?
|
||||
|
||||
**[A]** We are fully committed to providing our customers with working and stable bits and pieces in order to make successful OpenStack deployments. Please note that we do not distribute our own version of OpenStack; we rather provide a plain vanilla distribution. As such, there is no vendor lock-in. For convenience, our repository maintains the history of OpenStack packages certified to work with our Puppet manifests.
|
||||
**[A]** We are fully committed to providing our customers with working and
|
||||
stable bits and pieces in order to make successful OpenStack deployments.
|
||||
Please note that we do not distribute our own version of OpenStack; we rather
|
||||
provide a plain vanilla distribution. As such, there is no vendor lock-in.
|
||||
For convenience, our repository maintains the history of OpenStack packages
|
||||
certified to work with our Puppet manifests.
|
||||
|
||||
The advantage of this approach is that you can install any OpenStack version you want. If you are running Essex, just use the Puppet manifests which reference OpenStack packages for Essex from our repository. With each new release we add new OpenStack packages to our repository and created a separate branch with the Puppet manifests (which, in turn, reference these packages) corresponding to each release. With EPEL this would not be possible, as that repository only keeps the latest version for OpenStack packages.
|
||||
The advantage of this approach is that you can install any OpenStack version
|
||||
you want. If you are running Essex, just use the Puppet manifests which
|
||||
reference OpenStack packages for Essex from our repository. With each new
|
||||
release we add new OpenStack packages to our repository and created a
|
||||
separate branch with the Puppet manifests (which, in turn, reference these
|
||||
packages) corresponding to each release. With EPEL this would not be
|
||||
possible, as that repository only keeps the latest version for OpenStack
|
||||
packages.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
In this section, you’ll learn how to install OpenStack using Fuel. In
|
||||
addition to getting a feel for the steps involved, you’ll also gain valuable
|
||||
familiarity with some of the customization options. While Fuel provides
|
||||
different deployment configuration templates in the box, it is common for
|
||||
administrators to modify the architecture to meet enterprise requirements.
|
||||
Working hands on with Fuel for OpenStack will help you see how to move
|
||||
certain features around from the standard installation.
|
||||
|
||||
The first step, however, is to commit to a deployment template. A balanced,
|
||||
compact, and full-featured deployment is the Multi-node (HA) Compact
|
||||
deployment, so that’s what we’ll be using through the rest of this guide.
|
||||
|
||||
Production installations require a physical hardware infrastructure, but you
|
||||
can easily deploy a small simulation cloud on a single physical machine
|
||||
using VirtualBox. You can follow these instructions to install an OpenStack
|
||||
cloud into a test environment using VirtualBox, or to get a production-grade
|
||||
installation using physical hardware.
|
||||
|
|
@ -1,16 +1,23 @@
|
|||
How installation works
|
||||
----------------------
|
||||
|
||||
While version 2.0 of Fuel provided the ability to simplify installation of OpenStack, versions 2.1 and above include orchestration capabilities that simplify deployment of OpenStack clusters. The deployment process follows this general procedure:
|
||||
While version 2.0 of Fuel provided the ability to simplify installation of
|
||||
OpenStack, versions 2.1 and above include orchestration capabilities that
|
||||
simplify deployment of OpenStack clusters. The deployment process using
|
||||
Fuel CLI follows this general procedure:
|
||||
|
||||
#. Design your architecture.
|
||||
#. Install Fuel onto the fuel-pm machine.
|
||||
#. Configure Fuel.
|
||||
#. Create the basic configuration and load it into Cobbler.
|
||||
#. PXE-boot the servers so Cobbler can install the operating system and prepare them for orchestration.
|
||||
#. Use one of the templates included in Fuel and the configuration that populates Puppet's site.pp file.
|
||||
#. PXE-boot the servers so Cobbler can install the operating system and
|
||||
prepare them for orchestration.
|
||||
#. Use one of the templates included in Fuel and the configuration that
|
||||
populates Puppet's site.pp file.
|
||||
#. Customize the site.pp file as needed.
|
||||
#. Use the orchestrator to coordinate the installation of the appropriate OpenStack components on each node.
|
||||
#. Use the orchestrator to coordinate the installation of the appropriate
|
||||
OpenStack components on each node.
|
||||
|
||||
Start by designing your architecture, details about which you can find in the next section, :ref:`Before You Start <0015-before-you-start.rst>`
|
||||
Start by designing your architecture, details about which you can find in
|
||||
the next section, :ref:`Before You Start <0015-before-you-start.rst>`
|
||||
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
|
||||
Before You Start
|
||||
----------------
|
||||
|
||||
Before you begin your installation, you will need to make a number of
|
||||
important decisions:
|
||||
|
||||
**OpenStack features**
|
||||
Your first decision is to decide which of the
|
||||
optional OpenStack features you will need. For example, you must decide
|
||||
whether you want to install Swift, whether you want Glance to use Swift for
|
||||
image storage, whether you want Cinder for block storage, and whether you
|
||||
want nova-network or Quantum to handle your network
|
||||
connectivity. In our example installation we will be installing Glance with
|
||||
Swift support and Cinder for block storage. Also, due to the fact that it
|
||||
can be easily installed using orchestration, we will be using Quantum.
|
||||
|
||||
**Deployment configuration**
|
||||
Next, you need to decide whether your
|
||||
deployment requires high availability (HA). If you need HA for your
|
||||
deployment, you have a choice regarding the number of controllers you want
|
||||
to include. Following the recommendations in the previous section for a
|
||||
typical HA deployment configuration, we will use three OpenStack controllers.
|
||||
|
||||
**Cobbler server and Puppet Master.**
|
||||
The heart of any Fuel install is the
|
||||
combination of Puppet Master and Cobbler used to create your resources.
|
||||
Although Cobbler and Puppet Master can be installed on separate machines, it
|
||||
is common practice to install both on a single machine for small to medium
|
||||
size clouds, and that's what we'll be doing in this example. By default, the
|
||||
Fuel ISO creates a single server with both services.
|
||||
|
||||
**Domain name.**
|
||||
Puppet clients generate a Certificate Signing Request
|
||||
(CSR), which is then signed by the Puppet Master. The signed certificate can
|
||||
then be used to authenticate clients during provisioning. Certificate
|
||||
generation requires a fully qualified hostname, so you must choose a domain
|
||||
name to be used in your installation. Future versions of Fuel will enable
|
||||
you to choose this domain name on your own; by default, Fuel 3.1 uses
|
||||
``localdomain``.
|
||||
|
||||
**Network addresses.**
|
||||
OpenStack requires a minimum of three networks. If
|
||||
you are deploying on physical hardware, two of them -- the public network
|
||||
and the internal, or management network -- must be routable in your
|
||||
networking infrastructure. The third network is used by the nodes for
|
||||
inter-node communications. Also, if you intend for your cluster to be
|
||||
accessible from the Internet, you'll want the public network to be on the
|
||||
proper network segment. For simplicity in this case, this example assumes
|
||||
an Internet router at 192.168.0.1. Additionally, a set of private network
|
||||
addresses should be selected for automatic assignment to guest VMs. (These
|
||||
are fixed IPs for the private network). In our case, we are allocating
|
||||
network addresses as follows:
|
||||
|
||||
* Public network: 192.168.0.0/24
|
||||
* Internal network: 10.0.0.0/24
|
||||
* Private network: 10.0.1.0/24
|
||||
|
||||
**Network interfaces.**
|
||||
All of those networks need to be assigned to the
|
||||
available NIC cards on the allocated machines. Additionally, if a fourth NIC
|
||||
is available, Cinder or block storage traffic can be separated and delegated
|
||||
to the fourth NIC. In our case, we're assigning networks as follows:
|
||||
|
||||
* Public network: eth1
|
||||
* Internal network: eth0
|
||||
* Private network: eth2
|
||||
|
||||
|
|
@ -0,0 +1,307 @@
|
|||
Infrastructure Allocation and Installation
|
||||
------------------------------------------
|
||||
|
||||
The next step is to make sure that you have all of the required hardware and
|
||||
software in place.
|
||||
|
||||
Software
|
||||
^^^^^^^^
|
||||
|
||||
You can download the latest release of the Fuel ISO from
|
||||
http://fuel.mirantis.com/your-downloads/.
|
||||
|
||||
Alternatively, if you can't use the pre-built ISO, Mirantis offers the Fuel
|
||||
Library as a tar.gz file downloadable from the `Downloads
|
||||
<http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel portal.
|
||||
Using this file requires a bit more effort, but will yield the same results
|
||||
as using the ISO.
|
||||
|
||||
Network setup
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
OpenStack requires a minimum of three distinct networks: internal (or
|
||||
management), public, and private. The simplest and best methodology to map
|
||||
NICs is to assign each network to a different physical interface. However,
|
||||
not all machines have three NICs, and OpenStack can be configured and
|
||||
deployed with only two physical NICs, combining the internal and public
|
||||
traffic onto a single NIC.
|
||||
|
||||
If you are building a simulation environment, you are not limited to the
|
||||
availability of physical NICs. Allocate three NICs to each VM in your
|
||||
OpenStack infrastructure, one each for the internal, public, and private
|
||||
networks.
|
||||
|
||||
Finally, we assign network ranges to the internal, public, and private
|
||||
networks, and IP addresses to fuel-pm, fuel-controllers, and fuel-compute
|
||||
nodes. For deployment to a physical infrastructure you must work with your
|
||||
IT department to determine which IPs to use, but for the purposes of this
|
||||
exercise we will assume the below network and IP assignments:
|
||||
|
||||
#. 10.0.0.0/24: management or internal network, for communication between
|
||||
Puppet master and Puppet clients, as well as PXE/TFTP/DHCP for Cobbler.
|
||||
|
||||
#. 192.168.0.0/24: public network, for the High Availability (HA) Virtual IP
|
||||
(VIP), as well as floating IPs assigned to OpenStack guest VMs
|
||||
|
||||
#. 10.0.1.0/24: private network, fixed IPs automatically assigned to guest
|
||||
VMs by OpenStack upon their creation
|
||||
|
||||
Next we need to allocate a static IP address from the internal network to
|
||||
eth0 for fuel-pm, and eth1 for the controller, compute, and, if necessary,
|
||||
quantum nodes. For High Availability (HA) we must choose and assign an IP
|
||||
address from the public network to HAProxy running on the controllers. You
|
||||
can configure network addresses/network mask according to your needs, but
|
||||
our instructions assume the following network settings on the interfaces:
|
||||
|
||||
#. eth0: internal management network, where each machine is allocated a
|
||||
static IP address from a the defined pool of available addresses:
|
||||
|
||||
* 10.0.0.100 for Puppet Master
|
||||
* 10.0.0.101-10.0.0.103 for the controller nodes
|
||||
* 10.0.0.110-10.0.0.126 for the compute nodes
|
||||
* 10.0.0.10 internal Virtual IP for component access
|
||||
* 255.255.255.0 network mask
|
||||
|
||||
#. eth1: public network
|
||||
|
||||
* 192.168.0.10 public Virtual IP for access to the Horizon GUI
|
||||
(OpenStack management interface)
|
||||
|
||||
#. eth2: for communication between OpenStack VMs without IP address with
|
||||
promiscuous mode enabled.
|
||||
|
||||
Physical installation infrastructure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The hardware necessary for an installation depends on the choices you have
|
||||
made above. This sample installation requires the following hardware:
|
||||
|
||||
* 1 server to host both the Puppet Master and Cobbler. The minimum
|
||||
configuration for this server is:
|
||||
|
||||
* 32-bit or 64-bit architecture (64-bit recommended)
|
||||
|
||||
* 1+ CPU or vCPU for up to 10 nodes (2 vCPU for up to 20 nodes, 4 vCPU
|
||||
for up to 100 nodes)
|
||||
|
||||
* 1024+ MB of RAM for up to 10 nodes (4096+ MB for up to 20 nodes, 8192+
|
||||
MB for up to 100 nodes)
|
||||
|
||||
* 16+ GB of HDD for OS, and Linux distro storage
|
||||
|
||||
* 3 servers to act as OpenStack controllers (called fuel-controller-01,
|
||||
fuel-controller-02, and fuel-controller-03 for our sample deployment). The
|
||||
minimum configuration for a controller in Compact mode is:
|
||||
|
||||
* 64-bit architecture
|
||||
* 1+ CPU (2 or more CPUs or vCPUs recommended)
|
||||
* 1024+ MB of RAM (2048+ MB recommended)
|
||||
* 400+ GB of HDD
|
||||
|
||||
* 1 server to act as the OpenStack compute node (called fuel-compute-01).
|
||||
The minimum configuration for a compute node with Cinder installed is:
|
||||
|
||||
* 64-bit architecture
|
||||
* 2+ CPU, with Intel VTx or AMDV virtualization technology enabled
|
||||
* 2048+ MB of RAM
|
||||
* 1+ TB of HDD
|
||||
|
||||
If you choose to deploy Neutron (formerly Quantum) on a separate node, you
|
||||
will need an additional server with specifications comparable to the
|
||||
controller nodes.
|
||||
|
||||
Make sure your hardware is capable of PXE booting over the network from
|
||||
Cobbler. You'll also need each server's mac addresses.
|
||||
|
||||
For a list of certified hardware configurations, please `contact the
|
||||
Mirantis Services team <http://www.mirantis.com/contact/>`_.
|
||||
|
||||
Virtual installation infrastructure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For a virtual installation, you need only a single machine. You can get by
|
||||
on 8GB of RAM, but 16GB or more is recommended.
|
||||
|
||||
To perform the installation, you need a way to create Virtual Machines. This
|
||||
guide assumes that you are using version 4.2.12 or later of VirtualBox,
|
||||
which you can download from `the VirtualBox site
|
||||
<https://www.virtualbox.org/wiki/Downloads>`_. It is also required that you
|
||||
have the Extension Pack installed to enable features that are needed for a
|
||||
virtualized OpenStack test environment to work correctly.
|
||||
|
||||
You'll need to run VirtualBox on a stable host system. Mac OS 10.7.x, CentOS
|
||||
6.3+, or Ubuntu 12.04 are preferred; results in other operating systems are
|
||||
unpredictable. It's also important to remember that Windows is incapable of
|
||||
running the installation scripts for Fuel so we cannot recommend Windows as
|
||||
a test platform.
|
||||
|
||||
Configuring VirtualBox
|
||||
++++++++++++++++++++++
|
||||
|
||||
If you are on VirtualBox, please create the following host-only adapters and
|
||||
that they are configured correctly:
|
||||
|
||||
* VirtualBox -> File -> Preferences...
|
||||
|
||||
* Network -> Add HostOnly Adapter (vboxnet0)
|
||||
|
||||
* IPv4 Address: 10.0.0.1
|
||||
* IPv4 Network Mask: 255.255.255.0
|
||||
* DHCP server: disabled
|
||||
|
||||
* Network -> Add HostOnly Adapter (vboxnet1)
|
||||
|
||||
* IPv4 Address: 10.0.1.1
|
||||
* IPv4 Network Mask: 255.255.255.0
|
||||
* DHCP server: disabled
|
||||
|
||||
* Network -> Add HostOnly Adapter (vboxnet2)
|
||||
|
||||
* IPv4 Address: 0.0.0.0
|
||||
* IPv4 Network Mask: 255.255.255.0
|
||||
* DHCP server: disabled
|
||||
|
||||
In this example, only the first two adapters will be used. If necessasry,
|
||||
though, you can choose to use the third adapter to handle your storage
|
||||
network traffic.
|
||||
|
||||
After creating these interfaces, reboot the host machine to make sure that
|
||||
DHCP isn't running in the background.
|
||||
|
||||
As stated before, installing on Windows isn't recommended, but if you're
|
||||
attempting to do so you will also need to set up the IP address & network
|
||||
mask under Control Panel > Network and Internet > Network and Sharing Center
|
||||
for the Virtual HostOnly Network adapter.
|
||||
|
||||
Creating fuel-pm
|
||||
++++++++++++++++
|
||||
|
||||
The process of creating a virtual machine to host Fuel in VirtualBox depends
|
||||
on whether your deployment is purely virtual or consists of a physical or
|
||||
virtual fuel-pm controlling physical hardware. If your deployment is purely
|
||||
virtual then Adapter 1 may be a Hostonly adapter attached to vboxnet0, but
|
||||
if your deployment infrastructure consists of a virtual fuel-pm controlling
|
||||
physical machines Adapter 1 must be a Bridged Adapter and connected to
|
||||
whatever network interface of the host machine is connected to your physical
|
||||
machines.
|
||||
|
||||
To create fuel-pm, start up VirtualBox and create a new machine as follows:
|
||||
|
||||
* Machine -> New...
|
||||
|
||||
* Name: fuel-pm
|
||||
* Type: Linux
|
||||
* Version: Red Hat (64 Bit)
|
||||
* Memory: 2048 MB
|
||||
* Drive space: 16 GB HDD
|
||||
|
||||
* Machine -> Settings... -> Network
|
||||
|
||||
* Adapter 1
|
||||
|
||||
* Physical network
|
||||
|
||||
* Enable Network Adapter
|
||||
|
||||
* Attached to: Bridged Adapter
|
||||
|
||||
* Name: The host machine's network with access to the network on
|
||||
which the physical machines reside
|
||||
|
||||
* VirtualBox installation
|
||||
|
||||
* Enable Network Adapter
|
||||
|
||||
* Attached to: Hostonly Adapter
|
||||
|
||||
* Name: vboxnet0
|
||||
|
||||
* Adapter 2
|
||||
|
||||
* Enable Network Adapter
|
||||
|
||||
* Attached to: Bridged Adapter
|
||||
|
||||
* Name: eth0 (or whichever physical network is attached to the Internet)
|
||||
|
||||
* Machine -> Storage
|
||||
|
||||
* Attach the downloaded ISO as a drive
|
||||
|
||||
If you cannot or prefer not to install from the ISO, you can find
|
||||
instructions for installing from the Fuel Library in :ref:`Appendix A
|
||||
<Create-PM>`.
|
||||
|
||||
Creating the OpenStack nodes
|
||||
++++++++++++++++++++++++++++
|
||||
|
||||
If you're using VirtualBox, you will need to create the necessary virtual
|
||||
machines for your OpenStack nodes. Follow these instructions to create
|
||||
machines named fuel-controller-01, fuel-controller-02, fuel- controller-03,
|
||||
and fuel-compute-01. Please, do NOT start these virtual machines until
|
||||
instructed.
|
||||
|
||||
As you create each network adapter, click Advanced to expose and record the
|
||||
corresponding mac address.
|
||||
|
||||
* Machine -> New...
|
||||
|
||||
* Name: fuel-controller-01 (you will repeat these steps to create
|
||||
fuel-controller-02, fuel-controller-03, and fuel-compute-01)
|
||||
|
||||
* Type: Linux
|
||||
|
||||
* Version: Red Hat (64 Bit)
|
||||
|
||||
* Memory: 2048MB
|
||||
|
||||
* Drive space: 8GB
|
||||
|
||||
* Machine -> Settings -> System
|
||||
|
||||
* Check Network in Boot sequence
|
||||
|
||||
* Machine -> Settings -> Storage
|
||||
|
||||
* Controller: SATA
|
||||
|
||||
* Click the Add icon at the bottom of the Storage Tree pane and
|
||||
choose Add Disk
|
||||
|
||||
* Add a second VDI disk of 10GB for storage
|
||||
|
||||
* Machine -> Settings -> Network
|
||||
|
||||
* Adapter 1
|
||||
|
||||
* Enable Network Adapter
|
||||
|
||||
* Attached to: Hostonly Adapter
|
||||
|
||||
* Name: vboxnet0
|
||||
|
||||
* Adapter 2
|
||||
|
||||
* Enable Network Adapter
|
||||
|
||||
* Attached to: Bridged Adapter
|
||||
|
||||
* Name: eth0 (physical network attached to the Internet. You may
|
||||
also use a gateway if necessary.)
|
||||
|
||||
* Adapter 3
|
||||
|
||||
* Enable Network Adapter
|
||||
|
||||
* Attached to: Hostonly Adapter
|
||||
|
||||
* Name: vboxnet1
|
||||
|
||||
* Advanced -> Promiscuous mode: Allow All
|
||||
|
||||
It is important that Adapter 1 is configured to load first as Cobbler will
|
||||
use vboxnet0 for PXE and VirtualBox boots from the LAN using the first
|
||||
available network adapter.
|
||||
|
||||
The additional drive volume will be used as storage space by Cinder and will
|
||||
be configured automatically by Fuel.
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
.. _Generating_Puppet_Manifest:
|
||||
|
||||
Generating the Puppet Manifest
|
||||
------------------------------
|
||||
|
||||
Before you can deploy OpenStack using CLI, you will need to configure the
|
||||
`site.pp` file.
|
||||
To do this we included the ``openstack_system`` script, which uses the
|
||||
`config.yaml` file and reference architecture templates to create the
|
||||
appropriate Puppet manifest.
|
||||
|
||||
To create `site.pp`, execute this command::
|
||||
|
||||
openstack_system -c config.yaml \
|
||||
-t /etc/puppet/modules/openstack/examples/site_openstack_ha_compact.pp \
|
||||
-o /etc/puppet/manifests/site.pp \
|
||||
-a astute.yaml
|
||||
|
||||
The four parameters in the command above are:
|
||||
|
||||
``-c``:
|
||||
The absolute or relative path to the ``config.yaml`` file you customized earlier.
|
||||
|
||||
``-t``:
|
||||
The template file to serve as a basis for ``site.pp``.
|
||||
Possible templates include ``site_openstack_ha_compact.pp``,
|
||||
``site_openstack_ha_full.pp``, and ``site_openstack_simple.pp``.
|
||||
|
||||
``-o``:
|
||||
The output file. This should always be ``/etc/puppet/manifests/site.pp``.
|
||||
|
||||
``-a``:
|
||||
The orchestration configuration file, to be output for use in the next step.
|
||||
|
||||
From there you're ready to install your OpenStack components. Before that,
|
||||
however, let's look at what is actually in the new ``site.pp`` manifest, so
|
||||
that you can understand how to customize it if necessary.
|
||||
|
|
@ -3,29 +3,44 @@ Understanding the Puppet Manifest
|
|||
|
||||
.. contents:: :local:
|
||||
|
||||
At this point you should have functioning servers that are ready to take an OpenStack installation. If you're using VirtualBox, save the current state of every virtual machine by taking a snapshot using ``File->Take Snapshot``. Snapshots are a useful tool when you make a mistake, encounter an issue, or just want to try different configurations, all without having to start from scratch.
|
||||
At this point you should have functioning servers that are ready to take an
|
||||
OpenStack installation. If you're using VirtualBox, save the current state of
|
||||
every virtual machine by taking a snapshot using `File->Take Snapshot`.
|
||||
Snapshots are a useful tool when you made a mistake, encounter an issue, or just
|
||||
want to try different configurations, all without having to start from scratch.
|
||||
|
||||
Next, go through the ``/etc/puppet/manifests/site.pp`` file and make any necessary customizations. If you have run ``openstack_system``, there shouldn't be anything to change (with one small exception) but if you are installing Fuel manually, you will need to make these changes yourself.
|
||||
Next, go through the `/etc/puppet/manifests/site.pp` file and make any necessary
|
||||
customizations. If you have run ``openstack_system`` before, there shouldn't be
|
||||
anything to change.
|
||||
|
||||
Let's start with the basic network customization::
|
||||
Let's start with the basic network customization:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
### GENERAL CONFIG ###
|
||||
|
||||
# This section sets main parameters such as hostnames and IP addresses of different nodes
|
||||
|
||||
# This is the name of the public interface. The public network provides address space for Floating IPs, as well as public IP accessibility to the API endpoints.
|
||||
# This is the name of the public interface. The public network provides address
|
||||
# space for Floating IPs, as well as public IP accessibility to the API endpoints.
|
||||
$public_interface = 'eth1'
|
||||
$public_br = 'br-ex'
|
||||
|
||||
# This is the name of the internal interface. It will be attached to the management network, where data exchange between components of the OpenStack cluster will happen.
|
||||
# This is the name of the internal interface. It will be attached to the management
|
||||
# network, where data exchange between components of the OpenStack cluster will happen.
|
||||
$internal_interface = 'eth0'
|
||||
$internal_br = 'br-mgmt'
|
||||
|
||||
# This is the name of the private interface. All traffic within OpenStack tenants' networks will go through this interface.
|
||||
# This is the name of the private interface. All traffic within OpenStack tenants'
|
||||
# networks will go through this interface.
|
||||
$private_interface = 'eth2'
|
||||
|
||||
In this case, we don't need to make any changes to the interface settings, because they match what we've already set up. ::
|
||||
In this case, we don't need to make any changes to the interface settings,
|
||||
because they match what we've already set up:
|
||||
|
||||
# Public and Internal VIPs. These virtual addresses are required by HA topology and will be managed by keepalived.
|
||||
.. code-block:: ruby
|
||||
|
||||
# Public and Internal VIPs. These virtual addresses are required by HA topology
|
||||
$internal_virtual_ip = '10.0.0.10'
|
||||
|
||||
# Change this IP to IP routable from your 'public' network,
|
||||
|
|
@ -33,9 +48,15 @@ In this case, we don't need to make any changes to the interface settings, becau
|
|||
# interface resides
|
||||
$public_virtual_ip = '192.168.0.10'
|
||||
|
||||
Make sure the virtual IPs you see here don't conflict with your network configuration. The IPs you use should be routeable, but not within the range of a DHCP scope. These are the IPs through which your services will be accessed.
|
||||
Make sure the virtual IPs you see here don't conflict with your network
|
||||
configuration. The IPs you use should be routeable, but not within the range of
|
||||
a DHCP scope. These are the IPs through which your services will be accessed.
|
||||
|
||||
The following section configures the servers themselves. If you are setting up Fuel manually, make sure to add each server with the appropriate IP addresses; if you ran ``openstack_system``, the values will be overridden by the next section, and you can ignore this array. ::
|
||||
The following section configures the servers themselves. If you ran
|
||||
``openstack_system`` script, the values will be overridden by the next section,
|
||||
and you can ignore this array:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
$nodes_harr = [
|
||||
{
|
||||
|
|
@ -80,9 +101,13 @@ The following section configures the servers themselves. If you are setting up
|
|||
}
|
||||
]
|
||||
|
||||
Because this section comes from a template, it will likely include a number of servers you're not using; feel free to leave them or take them out.
|
||||
Because this section comes from a template, it will likely include a number of
|
||||
servers you're not using; feel free to leave them or take them out.
|
||||
|
||||
Next, the ``site.pp`` file lists all of the nodes and roles you defined in the ``config.yaml`` file::
|
||||
Next, the `site.pp` file lists all of the nodes and roles you defined in the
|
||||
`config.yaml` file:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
$nodes = [{'public_address' => '192.168.0.101','name' => 'fuel-controller-01','role' =>
|
||||
'primary-controller','internal_address' => '10.0.0.101',
|
||||
|
|
@ -99,43 +124,47 @@ Next, the ``site.pp`` file lists all of the nodes and roles you defined in the `
|
|||
{'public_address' => '192.168.0.110','name' => 'fuel-compute-01','role' =>
|
||||
'compute','internal_address' => '10.0.0.110'}]
|
||||
|
||||
Possible roles include ‘compute’, ‘controller’, ‘primary-controller’, ‘storage’, ‘swift-proxy’, ‘quantum’, ‘master’, and ‘cobbler’. Check the IP addresses for each node and make sure that they match the contents of this array.
|
||||
Possible roles include ‘compute’, ‘controller’, ‘primary-controller’, ‘storage’,
|
||||
‘swift-proxy’, ‘quantum’, ‘master’, and ‘cobbler’. Check the IP addresses for
|
||||
each node and make sure that they match the contents of this array.
|
||||
|
||||
The file also specifies the default gateway to be the fuel-pm machine::
|
||||
The file also specifies the default gateway to be the fuel-pm machine:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
$default_gateway = '192.168.0.1'
|
||||
|
||||
Next ``site.pp`` defines DNS servers and provides netmasks::
|
||||
Next lines in `site.pp` define DNS servers and provide netmasks:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
# Specify nameservers here.
|
||||
# You can point this to the cobbler node IP, or to specially prepared nameservers as needed.
|
||||
# You can point this to the cobbler node IP, or to specially prepared
|
||||
# nameservers as needed.
|
||||
$dns_nameservers = ['10.0.0.100','8.8.8.8']
|
||||
|
||||
# Specify netmasks for internal and external networks.
|
||||
$internal_netmask = '255.255.255.0'
|
||||
$public_netmask = '255.255.255.0'
|
||||
...
|
||||
# Set this to anything other than pacemaker if you do not want Neutron HA (formerly Quantum HA)
|
||||
# Also, if you do not want Neutron HA, you MUST enable $quantum_network_node
|
||||
# only on the controller
|
||||
# Set this to anything other than pacemaker if you do not want Quantum HA
|
||||
# Also, if you do not want Quantum in HA mode,
|
||||
# you should enable $quantum_network_node on the controller only
|
||||
$ha_provider = 'pacemaker'
|
||||
$use_unicast_corosync = false
|
||||
|
||||
Next specify the main controller as the Nagios master. ::
|
||||
|
||||
# Set nagios master fqdn
|
||||
$nagios_master = 'fuel-controller-01.localdomain'
|
||||
## proj_name name of environment nagios configuration
|
||||
$proj_name = 'test'
|
||||
|
||||
Here again we have a parameter that looks ahead to things to come; OpenStack supports monitoring via Nagios. In this section, you can choose the Nagios master server as well as setting a project name. ::
|
||||
..
|
||||
Here again we have a parameter that looks ahead to things to come.
|
||||
|
||||
#Specify if your installation contains multiple Nova controllers. Defaults to true as it is the most common scenario.
|
||||
$multi_host = true
|
||||
|
||||
A single host cloud isn't especially useful, but if you really want to, you can specify that here.
|
||||
|
||||
Finally, you can define the various usernames and passwords for OpenStack services. ::
|
||||
Finally, you can define the various usernames and passwords for OpenStack services:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
# Specify different DB credentials for various services
|
||||
$mysql_root_password = 'nova'
|
||||
|
|
@ -164,12 +193,16 @@ Finally, you can define the various usernames and passwords for OpenStack servic
|
|||
|
||||
# End DB credentials section
|
||||
|
||||
Now that the network is configured for the servers, let's look at the various OpenStack services.
|
||||
Now that the network is configured for the servers, let's look at the various
|
||||
OpenStack services.
|
||||
|
||||
Enabling Neutron
|
||||
Enabling Quantum
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
In order to deploy OpenStack with Neutron you need to set up an additional node that will act as an L3 router, or run Neutron out of one of the existing nodes. ::
|
||||
In order to deploy OpenStack with Quantum you need to run Quantum out of one of
|
||||
the existing nodes:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
### NETWORK/QUANTUM ###
|
||||
# Specify network/quantum specific settings
|
||||
|
|
@ -179,7 +212,8 @@ In order to deploy OpenStack with Neutron you need to set up an additional node
|
|||
$quantum = true
|
||||
$quantum_netnode_on_cnt = true
|
||||
|
||||
In this case, we're using a "compact" architecture, so we want to install Neutron on the controllers::
|
||||
In this case, we're using a "Compact" architecture, so we want to install Quantum
|
||||
on the controllers::
|
||||
|
||||
# Specify network creation criteria:
|
||||
# Should puppet automatically create networks?
|
||||
|
|
@ -191,39 +225,53 @@ In this case, we're using a "compact" architecture, so we want to install Neutro
|
|||
# Floating IP addresses are used for communication of VM instances with the outside world (e.g. Internet).
|
||||
$floating_range = '192.168.0.0/24'
|
||||
|
||||
OpenStack uses two ranges of IP addresses for virtual machines: fixed IPs, which are used for communication between VMs, and thus are part of the private network, and floating IPs, which are assigned to VMs for the purpose of communicating to and from the Internet. ::
|
||||
OpenStack uses two ranges of IP addresses for virtual machines: fixed IPs,
|
||||
which are used for communication between VMs, and thus are part of the private
|
||||
network, and floating IPs, which are assigned to VMs for the purpose of
|
||||
communicating to and from the Internet:
|
||||
|
||||
# These parameters are passed to the previously specified network manager , e.g. nova-manage network create.
|
||||
# Not used in Neutron.
|
||||
.. code-block:: ruby
|
||||
|
||||
# These parameters are passed to the previously specified network manager,
|
||||
# e.g. nova-manage network create.
|
||||
# Not used in Quantum.
|
||||
$num_networks = 1
|
||||
$network_size = 31
|
||||
$vlan_start = 300
|
||||
|
||||
These values don't actually relate to Neutron; they are used by nova-network. IDs for the VLANs OpenStack will create for tenants run from ``vlan_start`` to (``vlan_start + num_networks - 1``), and are generated automatically. ::
|
||||
These values don't actually relate to Quantum; they are used by nova-network.
|
||||
IDs for the VLANs OpenStack will create for tenants run from ``vlan_start`` to
|
||||
(``vlan_start + num_networks - 1``), and are generated automatically:
|
||||
|
||||
# Neutron
|
||||
.. code-block:: ruby
|
||||
|
||||
# Quantum
|
||||
|
||||
# Segmentation type for isolating traffic between tenants
|
||||
# Consult Openstack Neutron docs
|
||||
# Consult Openstack Quantum docs
|
||||
$tenant_network_type = 'gre'
|
||||
|
||||
# Which IP address will be used for creating GRE tunnels.
|
||||
$quantum_gre_bind_addr = $internal_address
|
||||
|
||||
If you are installing Neutron in non-HA mode, you will need to specify which single controller controls Neutron. ::
|
||||
If you are installing Quantum in non-HA mode, you will need to specify which
|
||||
single controller controls Quantum:
|
||||
|
||||
# If $external_ipinfo option is not defined, the addresses will be allocated automatically from $floating_range:
|
||||
.. code-block:: ruby
|
||||
|
||||
# If $external_ipinfo option is not defined, the addresses will be allocated
|
||||
# automatically from $floating_range:
|
||||
# the first address will be defined as an external default router,
|
||||
# the second address will be attached to an uplink bridge interface,
|
||||
# the remaining addresses will be utilized for the floating IP address pool.
|
||||
$external_ipinfo = {
|
||||
'pool_start' => '192.168.0.115',
|
||||
'public_net_router' => '192.168.0.1',
|
||||
'pool_end' => '192.168.0.126',
|
||||
'ext_bridge' => '0.0.0.0'
|
||||
'public_net_router' => '192.168.0.1',
|
||||
'pool_end' => '192.168.0.126',
|
||||
'ext_bridge' => '0.0.0.0'
|
||||
}
|
||||
|
||||
# Neutron segmentation range.
|
||||
# Quantum segmentation range.
|
||||
# For VLAN networks: valid VLAN VIDs can be 1 through 4094.
|
||||
# For GRE networks: Valid tunnel IDs can be any 32-bit unsigned integer.
|
||||
$segment_range = '900:999'
|
||||
|
|
@ -235,7 +283,7 @@ If you are installing Neutron in non-HA mode, you will need to specify which sin
|
|||
# Assign floating IPs to VMs on startup automatically?
|
||||
$auto_assign_floating_ip = false
|
||||
|
||||
# Database connection for Neutron configuration (quantum.conf)
|
||||
# Database connection for Quantum configuration (quantum.conf)
|
||||
$quantum_sql_connection = "mysql://${quantum_db_user}:${quantum_db_password}@${$internal_virtual_ip}/{quantum_db_dbname}"
|
||||
|
||||
if $quantum {
|
||||
|
|
@ -246,9 +294,12 @@ If you are installing Neutron in non-HA mode, you will need to specify which sin
|
|||
$internal_int = $internal_interface
|
||||
}
|
||||
|
||||
If the system is set up to use Neutron, the public and internal interfaces are set to use the appropriate bridges, rather than the defined interfaces.
|
||||
If the system is set up to use Quantum, the public and internal interfaces
|
||||
are set to use the appropriate bridges, rather than the defined interfaces.
|
||||
|
||||
The remaining configuration is used to define classes that will be added to each Neutron node::
|
||||
The remaining configuration is used to define classes that will be added to each Quantum node:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
#Network configuration
|
||||
stage {'netconfig':
|
||||
|
|
@ -296,22 +347,34 @@ The remaining configuration is used to define classes that will be added to each
|
|||
}
|
||||
### NETWORK/QUANTUM END ###
|
||||
|
||||
All of this assumes, of course, that you're using Neutron; if you're using nova-network instead, only these values apply.
|
||||
All of this assumes, of course, that you're using Quantum; if you're using
|
||||
nova-network instead, only these values apply.
|
||||
|
||||
Defining the current cluster
|
||||
Defining the Current Cluster
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fuel enables you to control multiple deployments simultaneously by setting an individual deployment ID::
|
||||
Fuel CLI enables you to control multiple deployments simultaneously by setting
|
||||
an individual deployment ID:
|
||||
|
||||
# This parameter specifies the the identifier of the current cluster. This is required for environments where you have multiple deployments.
|
||||
# installation. Each cluster requires a unique integer value.
|
||||
.. code-block:: ruby
|
||||
|
||||
# This parameter specifies the the identifier of the current cluster.
|
||||
# This is required for environments where you have multiple deployments.
|
||||
# Each cluster requires a unique integer value.
|
||||
# Valid identifier range is 0 to 254
|
||||
$deployment_id = '79'
|
||||
|
||||
Enabling Cinder
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
Our example uses Cinder, and with some very specific variations from the default. Specifically, as we said before, while the Cinder scheduler will continue to run on the controllers, the actual storage takes place on the compute nodes, specifically the ``/dev/sdb1`` partition you created earlier. Cinder will be activated on any node that contains the specified block devices -- unless specified otherwise -- so let's look at what all of that means for the configuration. ::
|
||||
Our example uses Cinder, and with some very specific variations from the default.
|
||||
Specifically, as we said before, while the Cinder scheduler will continue to
|
||||
run on the controllers, the actual storage takes place on the compute nodes,
|
||||
specifically the ``/dev/sdb1`` partition you created earlier. Cinder will be
|
||||
activated on any node that contains the specified block devices (unless
|
||||
specified otherwise) so let's look at what all of that means for the configuration:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
# Choose which nodes to install cinder onto
|
||||
# 'compute' -> compute nodes will run cinder
|
||||
|
|
@ -322,7 +385,10 @@ Our example uses Cinder, and with some very specific variations from the default
|
|||
# 'all' -> compute, controller, and storage nodes will run cinder (excluding swift and proxy nodes)
|
||||
$cinder_nodes = ['controller']
|
||||
|
||||
We want Cinder to be on the controller nodes, so set this value to ``['controller']``. ::
|
||||
We want Cinder to be on the controller nodes, so set this value to
|
||||
``['controller']``:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
# Set this option to true if cinder-volume has been installed to the host
|
||||
# otherwise it will install api and scheduler services
|
||||
|
|
@ -331,19 +397,26 @@ We want Cinder to be on the controller nodes, so set this value to ``['controlle
|
|||
# Setup network interface, which Cinder uses to export iSCSI targets.
|
||||
$cinder_iscsi_bind_addr = $internal_address
|
||||
|
||||
Here you have the opportunity to specify which network interface Cinder uses for its own traffic. For example, you could set up a fourth NIC at ``eth3`` and specify that rather than ``$internal_int``. ::
|
||||
Here you have the opportunity to specify which network interface Cinder uses for
|
||||
its own traffic. For example, you could set up a fourth NIC at ``eth3`` and
|
||||
specify that rather than ``$internal_int``:
|
||||
|
||||
# Below you can add physical volumes to cinder. Please replace values with the actual names of devices.
|
||||
# This parameter defines which partitions to aggregate into cinder-volumes or nova-volumes LVM VG
|
||||
.. code-block:: ruby
|
||||
|
||||
# Below you can add physical volumes to cinder.
|
||||
# Please replace values with the actual names of devices.
|
||||
# This parameter defines which partitions to aggregate into cinder-volumes
|
||||
# or nova-volumes LVM VG
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
# USE EXTREME CAUTION WITH THIS SETTING! IF THIS PARAMETER IS DEFINED,
|
||||
# IT WILL AGGREGATE THE VOLUMES INTO AN LVM VOLUME GROUP
|
||||
# AND ALL THE DATA THAT RESIDES ON THESE VOLUMES WILL BE LOST!
|
||||
# !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||
# Leave this parameter empty if you want to create [cinder|nova]-volumes VG by yourself
|
||||
# Leave this parameter empty if you want to create [cinder|nova]-volumes
|
||||
# VG by yourself
|
||||
$nv_physical_volume = ['/dev/sdb']
|
||||
|
||||
#Evaluate cinder node selection
|
||||
# Evaluate cinder node selection
|
||||
if ($cinder) {
|
||||
if (member($cinder_nodes,'all')) {
|
||||
$is_cinder_node = true
|
||||
|
|
@ -362,16 +435,27 @@ Here you have the opportunity to specify which network interface Cinder uses for
|
|||
|
||||
### CINDER/VOLUME END ###
|
||||
|
||||
We only want to allocate the ``/dev/sdb`` volume to Cinder, so adjust ``$nv_physical_volume`` accordingly. Note, however, that this is a global value; it will apply to all servers, including the controllers -- unless we specify otherwise, which we illustrate below.
|
||||
We only want to allocate the ``/dev/sdb`` volume to Cinder, so adjust
|
||||
``$nv_physical_volume`` accordingly. Note, however, that this is a global
|
||||
value; it will apply to all servers, including the controllers (unless we
|
||||
specify otherwise), which we illustrate below.
|
||||
|
||||
**Be careful** to not add block devices to the list which contain useful data (e.g. block devices on which your OS resides), as they will be destroyed after you allocate them for Cinder. It is always a good rule of thumb to deploy OpenStack on blank storage and move content to those volumes later instead of try to retain existing data.
|
||||
**Be careful** to do not add block devices to the list which contain useful data
|
||||
(e.g. block devices on which your OS resides), as they will be destroyed after
|
||||
you allocate them for Cinder. It is always a good rule of thumb to deploy
|
||||
OpenStack on blank storage and move content to those volumes later instead of
|
||||
try to retain existing data.
|
||||
|
||||
Now lets look at Swift, the other storage-based service option.
|
||||
Now let's look at Swift, the other storage-based service option.
|
||||
|
||||
Enabling Glance and Swift
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
There aren't many changes that you will need to make to the default configuration in order to enable Swift to work properly in Swift Compact mode, but you will need to adjust if you want to run Swift on physical partitions ::
|
||||
There aren't many changes that you will need to make to the default
|
||||
configuration in order to enable Swift to work properly in Compact mode,
|
||||
but you will need to adjust if you want to run Swift on physical partitions:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
...
|
||||
### GLANCE and SWIFT ###
|
||||
|
|
@ -386,9 +470,16 @@ There aren't many changes that you will need to make to the default configuratio
|
|||
# on physical partitions or inside loopback devices.
|
||||
$swift_loopback = loopback
|
||||
|
||||
The default value is ``loopback``, which tells Swift to use a loopback storage device, which is basically a file that acts like a drive, rather than a physical drive. You can also set this value to ``false``, which tells OpenStack to use a physical drive (or drives) instead. ::
|
||||
The default value is ``loopback``, which tells Swift to use a loopback storage
|
||||
device, which is basically a file that acts like a drive, rather than a physical
|
||||
drive. You can also set this value to ``false``, which tells OpenStack to use a
|
||||
physical drive (or drives) instead:
|
||||
|
||||
# Which IP address to bind swift components to: e.g., which IP swift-proxy should listen on
|
||||
.. code-block:: ruby
|
||||
|
||||
|
||||
# Which IP address to bind swift components to:
|
||||
# e.g., which IP swift-proxy should listen on
|
||||
$swift_local_net_ip = $internal_address
|
||||
|
||||
# IP node of controller used during swift installation
|
||||
|
|
@ -400,7 +491,9 @@ The default value is ``loopback``, which tells Swift to use a loopback storage d
|
|||
# of swift_proxy backends
|
||||
$swift_proxies = $controller_internal_addresses
|
||||
|
||||
Next, you're specifying the ``swift-master``::
|
||||
Next, you're specifying the ``swift-master``:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
# Set hostname of swift_master.
|
||||
# It tells on which swift proxy node to build
|
||||
|
|
@ -419,12 +512,16 @@ Next, you're specifying the ``swift-master``::
|
|||
$master_swift_proxy_nodes = filter_nodes($nodes,'role','primary-controller')
|
||||
$master_swift_proxy_ip = $master_swift_proxy_nodes[0]['internal_address']
|
||||
|
||||
In this case, there's no separate ``fuel-swiftproxy-01``, so the master controller will be the primary Swift controller.
|
||||
In this case, there's no separate ``fuel-swiftproxy-01``, so the master
|
||||
controller will be the primary Swift controller.
|
||||
|
||||
Configuring OpenStack to use syslog
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To use the syslog server, adjust the corresponding variables in the ``if $use_syslog`` clause::
|
||||
To use the syslog server, adjust the corresponding variables in the
|
||||
``if $use_syslog`` clause:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
$use_syslog = true
|
||||
if $use_syslog {
|
||||
|
|
@ -436,12 +533,17 @@ To use the syslog server, adjust the corresponding variables in the ``if $use_sy
|
|||
}
|
||||
}
|
||||
|
||||
For remote logging, use the IP or hostname of the server for the ``server`` value and set the ``port`` appropriately. For local logging, ``set log_local`` and ``log_auth_local`` to ``true``.
|
||||
For remote logging, use the IP or hostname of the server for the ``server``
|
||||
value and set the ``port`` appropriately. For local logging,
|
||||
set ``log_local`` and ``log_auth_local`` to ``true``.
|
||||
|
||||
Setting the version and mirror type
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
You can customize the various versions of OpenStack's components, though it's typical to use the latest versions::
|
||||
You can customize the various versions of OpenStack's components, though it's
|
||||
typical to use the latest versions:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
### Syslog END ###
|
||||
case $::osfamily {
|
||||
|
|
@ -453,7 +555,8 @@ You can customize the various versions of OpenStack's components, though it's ty
|
|||
}
|
||||
}
|
||||
# OpenStack packages and customized component versions to be installed.
|
||||
# Use 'latest' to get the most recent ones or specify exact version if you need to install custom version.
|
||||
# Use 'latest' to get the most recent ones or specify exact version
|
||||
# if you need to install custom version.
|
||||
$openstack_version = {
|
||||
'keystone' => 'latest',
|
||||
'glance' => 'latest',
|
||||
|
|
@ -464,22 +567,31 @@ You can customize the various versions of OpenStack's components, though it's ty
|
|||
'rabbitmq_version' => $rabbitmq_version_string,
|
||||
}
|
||||
|
||||
To tell Fuel to download packages from external repos provided by Mirantis and your distribution vendors, make sure the ``$mirror_type`` variable is set to ``default``::
|
||||
To tell Fuel to download packages from external repos provided by Mirantis and
|
||||
your distribution vendors, make sure the ``$mirror_type`` variable is set to
|
||||
``default``:
|
||||
|
||||
# If you want to set up a local repository, you will need to manually adjust mirantis_repos.pp,
|
||||
# though it is NOT recommended.
|
||||
.. code-block:: ruby
|
||||
|
||||
# If you want to set up a local repository, you will need to manually adjust
|
||||
# mirantis_repos.pp, though it is NOT recommended.
|
||||
$mirror_type = 'default'
|
||||
$enable_test_repo = false
|
||||
$repo_proxy = 'http://10.0.0.100:3128'
|
||||
|
||||
Once again, the ``$mirror_type`` **must** be set to ``default``. If you set it correctly in ``config.yaml`` and ran ``openstack_system`` this will already be taken care of. Otherwise, **make sure** to set this value manually.
|
||||
Once again, the ``$mirror_type`` **must** be set to ``default``.
|
||||
If you set it correctly in ``config.yaml`` and ran ``openstack_system`` this
|
||||
will already be taken care of. Otherwise, **make sure** to set this value manually.
|
||||
|
||||
Future versions of Fuel will enable you to use your own internal repositories.
|
||||
|
||||
Setting verbosity
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
You also have the option to determine how much information OpenStack provides when performing configuration::
|
||||
You also have the option to determine how much information OpenStack provides
|
||||
when performing configuration:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
# This parameter specifies the verbosity level of log messages
|
||||
# in openstack components config. Currently, it disables or enables debugging.
|
||||
|
|
@ -488,9 +600,16 @@ You also have the option to determine how much information OpenStack provides wh
|
|||
Configuring Rate-Limits
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Openstack has predefined limits on different HTTP queries for nova-compute and cinder services. Sometimes (e.g. for big clouds or test scenarios) these limits are too strict. (See http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-compute-API.html.) In this case you can change them to more appropriate values.
|
||||
OpenStack has predefined limits on different HTTP queries for nova-compute and
|
||||
cinder services. Sometimes (e.g. for big clouds or test scenarios) these limits
|
||||
are too strict. In this case you can change them to more appropriate values.
|
||||
|
||||
There are two hashes describing these limits: ``$nova_rate_limits`` and ``$cinder_rate_limits``. ::
|
||||
..seealso:: http://docs.openstack.org/folsom/openstack-compute/admin/content/configuring-compute-API.html
|
||||
|
||||
There are two hashes describing these limits: ``$nova_rate_limits`` and
|
||||
``$cinder_rate_limits``:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
#Rate Limits for cinder and Nova
|
||||
#Cinder and Nova can rate-limit your requests to API services.
|
||||
|
|
@ -513,17 +632,33 @@ There are two hashes describing these limits: ``$nova_rate_limits`` and ``$cinde
|
|||
Enabling Horizon HTTPS/SSL mode
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Using the ``$horizon_use_ssl`` variable, you have the option to decide whether the OpenStack dashboard (Horizon) uses HTTP or HTTPS::
|
||||
Using the ``$horizon_use_ssl`` variable, you have the option to decide whether
|
||||
the OpenStack dashboard (Horizon) uses HTTP or HTTPS:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
...
|
||||
# 'custom': require fileserver static mount point [ssl_certs] and hostname based certificate existence
|
||||
# 'custom': require fileserver static mount point [ssl_certs] and
|
||||
# hostname based certificate existence
|
||||
$horizon_use_ssl = false
|
||||
|
||||
This variable accepts the following values:
|
||||
|
||||
* ``false``: In this mode, the dashboard uses HTTP with no encryption.
|
||||
* ``default``: In this mode, the dashboard uses keys supplied with the standard Apache SSL module package.
|
||||
* ``exist``: In this case, the dashboard assumes that the domain name-based certificate, or keys, are provisioned in advance. This can be a certificate signed by any authorized provider, such as Symantec/Verisign, Comodo, GoDaddy, and so on. The system looks for the keys in these locations:
|
||||
`false`:
|
||||
In this mode, the dashboard uses HTTP with no encryption.
|
||||
|
||||
`default`:
|
||||
In this mode, the dashboard uses keys supplied with the standard Apache SSL
|
||||
module package.
|
||||
|
||||
`exist`:
|
||||
In this case, the dashboard assumes that the domain name-based certificate,
|
||||
or keys, are provisioned in advance. This can be a certificate signed by any
|
||||
authorized provider, such as Symantec/Verisign, Comodo, GoDaddy, and so on.
|
||||
The system looks for the keys in these locations:
|
||||
|
||||
* public ``/etc/pki/tls/certs/domain-name.crt``
|
||||
* private ``/etc/pki/tls/private/domain-name.key``
|
||||
|
||||
.. for Debian/Ubuntu:
|
||||
.. * public ``/etc/ssl/certs/domain-name.pem``
|
||||
|
|
@ -532,24 +667,34 @@ This variable accepts the following values:
|
|||
* public ``/etc/pki/tls/certs/domain-name.crt``
|
||||
* private ``/etc/pki/tls/private/domain-name.key``
|
||||
|
||||
* ``custom``: This mode requires a static mount point on the fileserver for ``[ssl_certs]`` and certificate pre-existence. To enable this mode, configure the puppet fileserver by editing ``/etc/puppet/fileserver.conf`` to add::
|
||||
`custom`:
|
||||
This mode requires a static mount point on the fileserver for ``[ssl_certs]``
|
||||
and certificate pre-existence. To enable this mode, configure the puppet
|
||||
fileserver by editing ``/etc/puppet/fileserver.conf`` to add::
|
||||
|
||||
[ssl_certs]
|
||||
path /etc/puppet/templates/ssl
|
||||
allow *
|
||||
[ssl_certs]
|
||||
path /etc/puppet/templates/ssl
|
||||
allow *
|
||||
|
||||
From there, create the appropriate directory::
|
||||
From there, create the appropriate directory::
|
||||
|
||||
mkdir -p /etc/puppet/templates/ssl
|
||||
mkdir -p /etc/puppet/templates/ssl
|
||||
|
||||
Add the certificates to this directory. (Reload the puppetmaster service for these changes to take effect.)
|
||||
Add the certificates to this directory.
|
||||
|
||||
Then reload the puppetmaster service for these changes to take effect.
|
||||
|
||||
Now we just need to make sure that all of our nodes get the proper values.
|
||||
|
||||
Defining the node configurations
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Now that we've set all of the global values, its time to make sure that the actual node definitions are correct. For example, by default all nodes will enable Cinder on ``/dev/sdb``. If you don't want to enable Cinder on all controllers set ``nv_physical_volume`` to ``null`` for a specific node or nodes. ::
|
||||
Now that we've set all of the global values, its time to make sure that the
|
||||
actual node definitions are correct. For example, by default all nodes will
|
||||
enable Cinder on ``/dev/sdb``. If you don't want to enable Cinder on all
|
||||
controllers set ``nv_physical_volume`` to ``null`` for a specific node or nodes:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
...
|
||||
class compact_controller (
|
||||
|
|
@ -574,147 +719,59 @@ Now that we've set all of the global values, its time to make sure that the actu
|
|||
}
|
||||
...
|
||||
|
||||
To reduce repeated manual configuration, Fuel includes a class for the controllers. This eliminates the need to make global changes for each individual controller. You will note that lower down in this configuration segment that this class also lets you specify the individual controllers and compute nodes::
|
||||
To reduce repeated manual configuration, Fuel includes a class for the controllers.
|
||||
This eliminates the need to make global changes for each individual controller.
|
||||
You will note that lower down in this configuration segment that this class also
|
||||
lets you specify the individual controllers and compute nodes:
|
||||
|
||||
.. code-block:: ruby
|
||||
|
||||
...
|
||||
node /fuel-controller-[\d+]/ {
|
||||
include stdlib
|
||||
class { 'operatingsystem::checksupported':
|
||||
stage => 'setup'
|
||||
}
|
||||
node /fuel-controller-[\d+]/ {
|
||||
include stdlib
|
||||
class { 'operatingsystem::checksupported':
|
||||
stage => 'setup'
|
||||
}
|
||||
|
||||
class {'::node_netconfig':
|
||||
mgmt_ipaddr => $::internal_address,
|
||||
mgmt_netmask => $::internal_netmask,
|
||||
public_ipaddr => $::public_address,
|
||||
public_netmask => $::public_netmask,
|
||||
stage => 'netconfig',
|
||||
}
|
||||
class {'::node_netconfig':
|
||||
mgmt_ipaddr => $::internal_address,
|
||||
mgmt_netmask => $::internal_netmask,
|
||||
public_ipaddr => $::public_address,
|
||||
public_netmask => $::public_netmask,
|
||||
stage => 'netconfig',
|
||||
}
|
||||
|
||||
class { compact_controller: }
|
||||
$swift_zone = $node[0]['swift_zone']
|
||||
|
||||
class {'nagios':
|
||||
proj_name => $proj_name,
|
||||
services => [
|
||||
'host-alive','nova-novncproxy','keystone', 'nova-scheduler',
|
||||
'nova-consoleauth', 'nova-cert', 'haproxy', 'nova-api', 'glance-api',
|
||||
'glance-registry','horizon', 'rabbitmq', 'mysql', 'swift-proxy',
|
||||
'swift-account', 'swift-container', 'swift-object',
|
||||
],
|
||||
whitelist => ['127.0.0.1', $nagios_master],
|
||||
hostgroup => 'controller',
|
||||
}
|
||||
|
||||
class { compact_controller: }
|
||||
$swift_zone = $node[0]['swift_zone']
|
||||
class { 'openstack::swift::storage_node':
|
||||
storage_type => $swift_loopback,
|
||||
swift_zone => $swift_zone,
|
||||
swift_local_net_ip => $internal_address,
|
||||
}
|
||||
|
||||
class { 'openstack::swift::storage_node':
|
||||
storage_type => $swift_loopback,
|
||||
swift_zone => $swift_zone,
|
||||
swift_local_net_ip => $internal_address,
|
||||
}
|
||||
|
||||
class { 'openstack::swift::proxy':
|
||||
swift_user_password => $swift_user_password,
|
||||
swift_proxies => $swift_proxies,
|
||||
class { 'openstack::swift::proxy':
|
||||
swift_user_password => $swift_user_password,
|
||||
swift_proxies => $swift_proxies,
|
||||
...
|
||||
rabbit_ha_virtual_ip => $internal_virtual_ip,
|
||||
}
|
||||
}
|
||||
rabbit_ha_virtual_ip => $internal_virtual_ip,
|
||||
}
|
||||
}
|
||||
|
||||
Note that each controller has the swift_zone specified, so each of the three controllers can represent each of the three Swift zones.
|
||||
Similarly, site.pp defines a class for the compute nodes.
|
||||
Note that each controller has the `swift_zone` specified, so each of the three
|
||||
controllers can represent each of the three Swift zones.
|
||||
Similarly, `site.pp` defines a class for the compute nodes.
|
||||
|
||||
Installing Nagios Monitoring using Puppet
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fuel provides a way to deploy Nagios for monitoring your OpenStack cluster. Nagios is an open source distributed management and monitoring infrastructure that is commonly used in data centers to keep an eye on thousands of servers. Nagios requires the installation of a software agent on all nodes, as well as having a master server for Nagios which will collect and display all the results. The agent, the Nagios NRPE addon, allows OpenStack to execute Nagios plugins on remote Linux/Unix machines. The main reason for doing this is to monitor key resources (such as CPU load, memory usage, etc.), as well as provide more advanced metrics and performance data on local and remote machines.
|
||||
|
||||
Nagios Agent
|
||||
++++++++++++
|
||||
|
||||
In order to install Nagios NRPE on a compute or controller node, a node should have the following settings: ::
|
||||
|
||||
class {'nagios':
|
||||
proj_name => 'test',
|
||||
services => ['nova-compute','nova-network','libvirt'],
|
||||
whitelist => ['127.0.0.1', $nagios_master],
|
||||
hostgroup => 'compute',
|
||||
}
|
||||
|
||||
* ``proj_name``: An environment for nagios commands and the directory (``/etc/nagios/test/``).
|
||||
* ``services``: All services to be monitored by nagios.
|
||||
* ``whitelist``: The array of IP addreses trusted by NRPE.
|
||||
* ``hostgroup``: The group to be used in the nagios master (do not forget create the group in the nagios master).
|
||||
|
||||
Nagios Server
|
||||
+++++++++++++
|
||||
|
||||
In order to install Nagios Master on any convenient node, a node should have the following applied: ::
|
||||
|
||||
class {'nagios::master':
|
||||
proj_name => 'test',
|
||||
templatehost => {'name' => 'default-host','check_interval' => '10'},
|
||||
templateservice => {'name' => 'default-service' ,'check_interval'=>'10'},
|
||||
hostgroups => ['compute','controller'],
|
||||
contactgroups => {'group' => 'admins', 'alias' => 'Admins'},
|
||||
contacts => {'user' => 'hotkey', 'alias' => 'Dennis Hoppe',
|
||||
'email' => 'nagios@%{domain}',
|
||||
'group' => 'admins'},
|
||||
}
|
||||
|
||||
* ``proj_name``: The environment for nagios commands and the directory (``/etc/nagios/test/``).
|
||||
* ``templatehost``: The group of checks and intervals parameters for hosts (as a Hash).
|
||||
* ``templateservice``: The group of checks and intervals parameters for services (as a Hash).
|
||||
* ``hostgroups``: All groups which on NRPE nodes (as an Array).
|
||||
* ``contactgroups``: The group of contacts (as a Hash).
|
||||
* ``contacts``: Contacts to receive error reports (as a Hash)
|
||||
|
||||
Health Checks
|
||||
+++++++++++++
|
||||
|
||||
You can see the complete definition of the available services to monitor and their health checks at ``deployment/puppet/nagios/manifests/params.pp``.
|
||||
|
||||
Here is the list: ::
|
||||
|
||||
$services_list = {
|
||||
'nova-compute' => 'check_nrpe_1arg!check_nova_compute',
|
||||
'nova-network' => 'check_nrpe_1arg!check_nova_network',
|
||||
'libvirt' => 'check_nrpe_1arg!check_libvirt',
|
||||
'swift-proxy' => 'check_nrpe_1arg!check_swift_proxy',
|
||||
'swift-account' => 'check_nrpe_1arg!check_swift_account',
|
||||
'swift-container' => 'check_nrpe_1arg!check_swift_container',
|
||||
'swift-object' => 'check_nrpe_1arg!check_swift_object',
|
||||
'swift-ring' => 'check_nrpe_1arg!check_swift_ring',
|
||||
'keystone' => 'check_http_api!5000',
|
||||
'nova-novncproxy' => 'check_nrpe_1arg!check_nova_novncproxy',
|
||||
'nova-scheduler' => 'check_nrpe_1arg!check_nova_scheduler',
|
||||
'nova-consoleauth' => 'check_nrpe_1arg!check_nova_consoleauth',
|
||||
'nova-cert' => 'check_nrpe_1arg!check_nova_cert',
|
||||
'cinder-scheduler' => 'check_nrpe_1arg!check_cinder_scheduler',
|
||||
'cinder-volume' => 'check_nrpe_1arg!check_cinder_volume',
|
||||
'haproxy' => 'check_nrpe_1arg!check_haproxy',
|
||||
'memcached' => 'check_nrpe_1arg!check_memcached',
|
||||
'nova-api' => 'check_http_api!8774',
|
||||
'cinder-api' => 'check_http_api!8776',
|
||||
'glance-api' => 'check_http_api!9292',
|
||||
'glance-registry' => 'check_nrpe_1arg!check_glance_registry',
|
||||
'horizon' => 'check_http_api!80',
|
||||
'rabbitmq' => 'check_rabbitmq',
|
||||
'mysql' => 'check_galera_mysql',
|
||||
'apt' => 'nrpe_check_apt',
|
||||
'kernel' => 'nrpe_check_kernel',
|
||||
'libs' => 'nrpe_check_libs',
|
||||
'load' => 'nrpe_check_load!5.0!4.0!3.0!10.0!6.0!4.0',
|
||||
'procs' => 'nrpe_check_procs!250!400',
|
||||
'zombie' => 'nrpe_check_procs_zombie!5!10',
|
||||
'swap' => 'nrpe_check_swap!20%!10%',
|
||||
'user' => 'nrpe_check_users!5!10',
|
||||
'host-alive' => 'check-host-alive',
|
||||
}
|
||||
.. include /pages/installation-fuel-cli/0065-install nagios.rst
|
||||
|
||||
Node definitions
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The following is a list of the node definitions generated for a Compact HA deployment. Other deployment configurations generate other definitions. For example, the ``openstack/examples/site_openstack_full.pp`` template specifies the following nodes:
|
||||
The following is a list of the node definitions generated for a Compact HA
|
||||
deployment. Other deployment configurations generate other definitions.
|
||||
|
||||
For example, the `openstack/examples/site_openstack_full.pp` template specifies
|
||||
the following nodes:
|
||||
|
||||
* fuel-controller-01
|
||||
* fuel-controller-02
|
||||
|
|
@ -726,6 +783,7 @@ The following is a list of the node definitions generated for a Compact HA deplo
|
|||
* fuel-swiftproxy-[\d+]
|
||||
* fuel-quantum
|
||||
|
||||
Using this architecture, the system includes three stand-alone swift-storage servers, and one or more swift-proxy servers.
|
||||
Using this architecture, the system includes three stand-alone swift-storage
|
||||
servers, and one or more swift-proxy servers.
|
||||
|
||||
With ``site.pp`` prepared, you're ready to perform the actual installation.
|
||||
With `site.pp` prepared, you're ready to perform the actual installation.
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
Installing Nagios Monitoring using Puppet
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fuel provides a way to deploy Nagios for monitoring your OpenStack cluster. Nagios is an open source distributed management and monitoring infrastructure that is commonly used in data centers to keep an eye on thousands of servers. Nagios requires the installation of a software agent on all nodes, as well as having a master server for Nagios which will collect and display all the results. The agent, the Nagios NRPE addon, allows OpenStack to execute Nagios plugins on remote Linux/Unix machines. The main reason for doing this is to monitor key resources (such as CPU load, memory usage, etc.), as well as provide more advanced metrics and performance data on local and remote machines.
|
||||
|
||||
Nagios Agent
|
||||
++++++++++++
|
||||
|
||||
In order to install Nagios NRPE on a compute or controller node, a node should have the following settings: ::
|
||||
|
||||
class {'nagios':
|
||||
proj_name => 'test',
|
||||
services => ['nova-compute','nova-network','libvirt'],
|
||||
whitelist => ['127.0.0.1', $nagios_master],
|
||||
hostgroup => 'compute',
|
||||
}
|
||||
|
||||
* ``proj_name``: An environment for nagios commands and the directory (``/etc/nagios/test/``).
|
||||
* ``services``: All services to be monitored by nagios.
|
||||
* ``whitelist``: The array of IP addreses trusted by NRPE.
|
||||
* ``hostgroup``: The group to be used in the nagios master (do not forget create the group in the nagios master).
|
||||
|
||||
Nagios Server
|
||||
+++++++++++++
|
||||
|
||||
In order to install Nagios Master on any convenient node, a node should have the following applied: ::
|
||||
|
||||
class {'nagios::master':
|
||||
proj_name => 'test',
|
||||
templatehost => {'name' => 'default-host','check_interval' => '10'},
|
||||
templateservice => {'name' => 'default-service' ,'check_interval'=>'10'},
|
||||
hostgroups => ['compute','controller'],
|
||||
contactgroups => {'group' => 'admins', 'alias' => 'Admins'},
|
||||
contacts => {'user' => 'hotkey', 'alias' => 'Dennis Hoppe',
|
||||
'email' => 'nagios@%{domain}',
|
||||
'group' => 'admins'},
|
||||
}
|
||||
|
||||
* ``proj_name``: The environment for nagios commands and the directory (``/etc/nagios/test/``).
|
||||
* ``templatehost``: The group of checks and intervals parameters for hosts (as a Hash).
|
||||
* ``templateservice``: The group of checks and intervals parameters for services (as a Hash).
|
||||
* ``hostgroups``: All groups which on NRPE nodes (as an Array).
|
||||
* ``contactgroups``: The group of contacts (as a Hash).
|
||||
* ``contacts``: Contacts to receive error reports (as a Hash)
|
||||
|
||||
Health Checks
|
||||
+++++++++++++
|
||||
|
||||
You can see the complete definition of the available services to monitor and their health checks at ``deployment/puppet/nagios/manifests/params.pp``.
|
||||
|
||||
Here is the list: ::
|
||||
|
||||
$services_list = {
|
||||
'nova-compute' => 'check_nrpe_1arg!check_nova_compute',
|
||||
'nova-network' => 'check_nrpe_1arg!check_nova_network',
|
||||
'libvirt' => 'check_nrpe_1arg!check_libvirt',
|
||||
'swift-proxy' => 'check_nrpe_1arg!check_swift_proxy',
|
||||
'swift-account' => 'check_nrpe_1arg!check_swift_account',
|
||||
'swift-container' => 'check_nrpe_1arg!check_swift_container',
|
||||
'swift-object' => 'check_nrpe_1arg!check_swift_object',
|
||||
'swift-ring' => 'check_nrpe_1arg!check_swift_ring',
|
||||
'keystone' => 'check_http_api!5000',
|
||||
'nova-novncproxy' => 'check_nrpe_1arg!check_nova_novncproxy',
|
||||
'nova-scheduler' => 'check_nrpe_1arg!check_nova_scheduler',
|
||||
'nova-consoleauth' => 'check_nrpe_1arg!check_nova_consoleauth',
|
||||
'nova-cert' => 'check_nrpe_1arg!check_nova_cert',
|
||||
'cinder-scheduler' => 'check_nrpe_1arg!check_cinder_scheduler',
|
||||
'cinder-volume' => 'check_nrpe_1arg!check_cinder_volume',
|
||||
'haproxy' => 'check_nrpe_1arg!check_haproxy',
|
||||
'memcached' => 'check_nrpe_1arg!check_memcached',
|
||||
'nova-api' => 'check_http_api!8774',
|
||||
'cinder-api' => 'check_http_api!8776',
|
||||
'glance-api' => 'check_http_api!9292',
|
||||
'glance-registry' => 'check_nrpe_1arg!check_glance_registry',
|
||||
'horizon' => 'check_http_api!80',
|
||||
'rabbitmq' => 'check_rabbitmq',
|
||||
'mysql' => 'check_galera_mysql',
|
||||
'apt' => 'nrpe_check_apt',
|
||||
'kernel' => 'nrpe_check_kernel',
|
||||
'libs' => 'nrpe_check_libs',
|
||||
'load' => 'nrpe_check_load!5.0!4.0!3.0!10.0!6.0!4.0',
|
||||
'procs' => 'nrpe_check_procs!250!400',
|
||||
'zombie' => 'nrpe_check_procs_zombie!5!10',
|
||||
'swap' => 'nrpe_check_swap!20%!10%',
|
||||
'user' => 'nrpe_check_users!5!10',
|
||||
'host-alive' => 'check-host-alive',
|
||||
}
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
Deploying OpenStack using Puppet Manifests
|
||||
------------------------------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
You have two options for deploying OpenStack using Puppet manifests. The best
|
||||
method is to use orchestration, but you can also deploy your nodes manually.
|
||||
|
||||
.. _orchestration:
|
||||
|
||||
Deploying via Orchestration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Performing a small series of manual installs many be an acceptable approach in
|
||||
some circumstances, but if you plan on deploying to a large number of servers
|
||||
then we strongly suggest that you consider orchestration. You can perform a
|
||||
deployment using orchestration with Fuel using the "astute" script. This script
|
||||
is configured using the `astute.yaml` file that was created when you ran
|
||||
``openstack_system`` earlier in this process.
|
||||
|
||||
To confirm that your servers are ready for orchestration, execute the following
|
||||
command::
|
||||
|
||||
mco ping
|
||||
|
||||
You should see all three controllers, plus the compute node, in the response to
|
||||
the command::
|
||||
|
||||
fuel-compute-01 time=107.26 ms
|
||||
fuel-controller-01 time=120.14 ms
|
||||
fuel-controller-02 time=135.94 ms
|
||||
fuel-controller-03 time=139.33 ms
|
||||
|
||||
To run the orchestrator, log in to ``fuel-pm`` and execute::
|
||||
|
||||
astute -f astute.yaml
|
||||
|
||||
You will see a message on ``fuel-pm`` stating that the installation has started
|
||||
on fuel-controller-01.
|
||||
|
||||
To see what's going on on the target node, enter this command::
|
||||
|
||||
tail -f /var/log/messages
|
||||
|
||||
Note that Puppet will require several runs to install all the different roles.
|
||||
The first time it runs, the orchestrator will show an error. This error means
|
||||
that the installation isn't complete, but will be rectified after the various
|
||||
rounds of installation are completed. Also, after the first run on each server,
|
||||
the orchestrator doesn't output messages on fuel-pm; when it's finished running,
|
||||
it will return you to the command prompt. In the meantime, you can see what's
|
||||
going on by watching the logs on each individual machine.
|
||||
|
||||
Installing OpenStack using Puppet directly
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If, for some reason, you choose not to use orchestration (one common example is
|
||||
adding a single node to an existing (non-HA) cluster) you have the option to
|
||||
install on one or more nodes using Puppet manually.
|
||||
|
||||
Start by logging in to the target server (`fuel-controller-01` to start, if you're
|
||||
starting from scratch) and running the Puppet agent.
|
||||
|
||||
One optional step would be to use the ``script`` command to log all of your output
|
||||
so you can check for errors::
|
||||
|
||||
script agent-01.log
|
||||
puppet agent --test
|
||||
|
||||
You will to see a great number of messages scroll by, and the installation will
|
||||
take a significant amount of time. When the process has completed, press CTRL-D
|
||||
to stop logging and grep for errors::
|
||||
|
||||
grep err: agent-01.log
|
||||
|
||||
If you find any errors relating to other nodes you may safely ignore them
|
||||
for now.
|
||||
|
||||
Now you can run the same installation procedure on fuel-controller-02 and
|
||||
fuel-controller-03, as well as fuel-compute-01.
|
||||
|
||||
Note that the controllers must be installed sequentially due to the nature of
|
||||
assembling a MySQL cluster based on Galera. This means that one server must
|
||||
complete its installation before the next installation is started. However,
|
||||
compute nodes can be installed concurrently once the controllers are in place.
|
||||
|
||||
In some cases, you may find errors related to resources that are not yet
|
||||
available when the installation takes place. To solve that problem, simply
|
||||
re-run the puppet agent on the affected node after running the other
|
||||
controllers, and again grep for error messages. When you see no errors on any
|
||||
of your nodes, your OpenStack cluster is ready to go.
|
||||
|
||||
Examples of OpenStack installation sequences
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When running Puppet manually, the exact sequence depends on the configuration
|
||||
goals you're trying to achieve. In most cases, you'll need to run Puppet more
|
||||
than once; with every pass Puppet collects and adds necessary absent information
|
||||
to the OpenStack configuration, stores and applies necessary changes.
|
||||
|
||||
.. note::
|
||||
|
||||
*Sequentially run* means you don't start the next node deployment until
|
||||
previous one is finished.
|
||||
|
||||
**Example 1: Full OpenStack deployment with standalone storage nodes**
|
||||
|
||||
* Create necessary volumes on storage nodes as described in :ref:`create-the-XFS-partition`.
|
||||
* Sequentially run a deployment pass on every SwiftProxy node
|
||||
(fuel-swiftproxy-01 ... fuel-swiftproxy-xx), starting with the
|
||||
`primary-swift-proxy` node. Node names are set by the ``$swift_proxies``
|
||||
variable in `site.pp`. There are 2 Swift Proxies by default.
|
||||
* Sequentially run a deployment pass on every storage node (fuel-swift-01 ...
|
||||
fuel-swift-xx).
|
||||
* Sequentially run a deployment pass on the controller nodes
|
||||
(fuel-controller-01 ... fuel-controller-xx) starting with the
|
||||
`primary-controller` node.
|
||||
* Run a deployment pass on every Compute node (fuel-compute-01 ...
|
||||
fuel-compute-xx) - unlike the controllers, these nodes may be deployed in parallel.
|
||||
* Run an additional deployment pass on `fuel-controller-01` to finalize the
|
||||
Galera cluster configuration.
|
||||
|
||||
**Example 2: Compact OpenStack deployment with storage and swift-proxy
|
||||
combined with nova-controller on the same nodes**
|
||||
|
||||
* Create the necessary volumes on controller nodes as described
|
||||
in :ref:`create-the-XFS-partition`
|
||||
* Sequentially run a deployment pass on the controller nodes
|
||||
(fuel-controller-01 ... fuel-controller-xx), starting with the
|
||||
`primary-controller` node. Errors in Swift storage such as ``*/Stage[main]
|
||||
/Swift::Storage::Container/Ring_container_device[<device address>]: Could not
|
||||
evaluate: Device not found check device on <device address>*`` are expected
|
||||
during the deployment passes until the very final pass.
|
||||
* Run an additional deployment pass on `fuel-controller-01` only to finalize the
|
||||
Galera cluster configuration.
|
||||
* Run a deployment pass on every compute node (fuel-compute-01 ...
|
||||
fuel-compute-xx) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
||||
**Example 3:** **Simple OpenStack non-HA installation**
|
||||
|
||||
* Sequentially run a deployment pass on the controller (`fuel-controller-01`).
|
||||
No errors should appear during this deployment pass.
|
||||
* Run a deployment pass on every compute node (`fuel-compute-01` ...
|
||||
`fuel-compute-xx`) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
Testing OpenStack
|
||||
-----------------
|
||||
|
||||
Now that you've installed OpenStack, its time to take your new OpenStack cloud
|
||||
for a drive around the block. Follow these steps:
|
||||
|
||||
1. On the host machine, open your browser to http://192.168.0.10/ (change the
|
||||
IP address value to your own ``public_virtual_ip``) and login as
|
||||
``nova/nova`` (unless you changed these credentials in ``site.pp``)
|
||||
|
||||
2. Click the ``Project`` tab in the left-hand column.
|
||||
|
||||
3. Under ``Manage Compute``, choose ``Access & Security`` to set security
|
||||
settings:
|
||||
|
||||
- Click ``Create Keypair`` and enter a name for the new keypair. The
|
||||
private key should download automatically; make sure to keep it safe.
|
||||
|
||||
- Click ``Access & Security`` again and click ``Edit Rules`` for the
|
||||
default Security Group.
|
||||
|
||||
- Add a new rule allowing TCP connections from
|
||||
port 22 to port 22 for all IP addresses using a CIDR of 0.0.0.0/0.
|
||||
(You can also customize this setting as necessary.)
|
||||
|
||||
- Click ``Add Rule`` to save the new rule.
|
||||
|
||||
- Add a second new rule allowing ICMP connections with a type and code of
|
||||
-1 to the default Security Group and click ``Add Rule`` to save.
|
||||
|
||||
4. Click ``Allocate IP To Project`` and add two new floating IPs. Notice that
|
||||
they come from the pool specified in ``config.yaml`` and ``site.pp``.
|
||||
|
||||
5. Click ``Images & Snapshots``, then ``Create Image``.
|
||||
|
||||
- Enter a name and specify the ``Image Location`` as
|
||||
https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.
|
||||
img, with a ``Format`` of ``QCOW2``. Check the ``Public`` checkbox.
|
||||
|
||||
6. The next step is to upload an image to use for creating VMs, but an OpenStack
|
||||
bug prevents you from doing this in the browser. Instead, log in to any
|
||||
of the controllers as ``root`` and execute the following commands::
|
||||
|
||||
cd ~
|
||||
source openrc
|
||||
glance image-create --name cirros --container-format bare --disk-format qcow2 --is-public yes \
|
||||
--location https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img
|
||||
|
||||
7. Go back to the browser and refresh the page. Launch a new instance of this image
|
||||
using the tiny flavor. Click the ``Networking`` tab and choose the
|
||||
default ``net04_ext`` network, then click the Launch button.
|
||||
|
||||
8. On the instances page:
|
||||
|
||||
- Click the new instance and look at the settings.
|
||||
|
||||
- Click the ``Logs`` tab to look at the logs.
|
||||
|
||||
- Click the ``VNC`` tab to log in. If you see just a big black rectangle, the
|
||||
machine is in screensaver mode; click the grey area and press the space
|
||||
bar to wake it up, then login as ``cirros/cubswin:)``.
|
||||
|
||||
- At the command line, enter ``ifconfig -a | more`` and see the assigned IP address.
|
||||
|
||||
- Enter ``sudo fdisk -l`` to see that no volume has yet been assigned to this VM.
|
||||
|
||||
9. On the ``Instances`` page, click ``Assign Floating IP`` and assign an IP
|
||||
address to your instance. You can either choose from one of the existing
|
||||
created IPs by using the pulldown menu or click the plus sign (+) to choose
|
||||
a network and allocate a new IP address.
|
||||
|
||||
- From your host machine, ping the floating IP assigned to this VM.
|
||||
|
||||
- If that works, try to ``ssh cirros@floating-ip`` from the host machine.
|
||||
|
||||
10. Back in the browser, click ``Volumes`` and ``Create Volume``. Create the
|
||||
new volume, and attach it to the instance.
|
||||
|
||||
11. Go back to the VNC tab and repeat ``fdisk -l`` to see the new unpartitioned
|
||||
disk attached.
|
||||
|
||||
Now your new VM is ready to be used.
|
||||
|
|
@ -20,7 +20,7 @@ common:
|
|||
pool_start: 10.49.54.225
|
||||
pool_end: 10.49.54.239
|
||||
segment_range: 900:999
|
||||
tenant_network_type: vlan
|
||||
tenant_network_type: gre
|
||||
network_manager: nova.network.manager.FlatDHCPManager
|
||||
auto_assign_floating_ip: true
|
||||
quantum_netnode_on_cnt: true
|
||||
|
|
@ -0,0 +1,277 @@
|
|||
.. index:: Installing Fuel Master Node
|
||||
|
||||
Installing Fuel Master Node
|
||||
===========================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Fuel is distributed as both ISO and IMG images, each of them contains
|
||||
an installer for Fuel Master node. The ISO image is used for CD media devices,
|
||||
iLO or similar remote access systems. The IMG file is used for USB memory sticks.
|
||||
|
||||
Once installed, Fuel can be used to deploy and manage OpenStack clusters. It
|
||||
will assign IP addresses to the nodes, perform PXE boot and initial
|
||||
configuration, and provision of OpenStack nodes according to their roles in
|
||||
the cluster.
|
||||
|
||||
.. _Install_Bare-Metal:
|
||||
|
||||
On Bare-Metal Environment
|
||||
-------------------------
|
||||
|
||||
To install Fuel on bare-metal environment, you need to burn the provided ISO
|
||||
to a CD/DVD, or IMG file to a USB stick, and start the installation process
|
||||
by booting from that media, very much like any other OS.
|
||||
|
||||
Linux and Mac users can prepare an installation USB stick with the ``dd``
|
||||
command. For example, if your flash drive is ``/dev/sdb``, you can use
|
||||
following command line::
|
||||
|
||||
dd if=fuel.img of=/dev/sdb
|
||||
|
||||
You can find the actual device name in the output of the ``dmesg`` command for
|
||||
Linux or ``diskutil list`` for Mac OS.
|
||||
|
||||
On Windows, you can write the installation image with
|
||||
`Win32 Disk Imager <http://sourceforge.net/projects/win32diskimager/>`_.
|
||||
|
||||
After the installation is complete, you will need to allocate bare-metal nodes for
|
||||
your OpenStack cluster, put them on the same L2 network as the Master Node, and
|
||||
boot them via PXE. The UI will automatically discover new nodes and make them
|
||||
available for OpenStack installation.
|
||||
|
||||
On VirtualBox
|
||||
-------------
|
||||
|
||||
If you are going to evaluate Fuel on VirtualBox, you should know that we
|
||||
provide a set of scripts that create and configure all of the required VMs for
|
||||
you, including the Master Node and Slave Nodes for OpenStack itself. It's a very
|
||||
simple, single-click installation.
|
||||
|
||||
.. note:: These scripts are not supported on Windows, but you can still test on
|
||||
VirtualBox by creating the VMs by yourself. See :ref:`Manual_Mode` for more
|
||||
details.
|
||||
|
||||
The requirements for running Fuel on VirtualBox are:
|
||||
|
||||
A host machine with Linux or Mac OS.
|
||||
The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, and Ubuntu 12.04.
|
||||
|
||||
VirtualBox 4.2.12 (or later) must be installed with the extension pack. Both
|
||||
can be downloaded from `<http://www.virtualbox.org/>`_.
|
||||
|
||||
8 GB+ of RAM
|
||||
to handle 4 VMs for non-HA OpenStack installation (1 Master node, 1 Controller
|
||||
node, 1 Compute node, 1 Cinder node) or
|
||||
to handle 5 VMs for HA OpenStack installation (1 Master node, 3 Controller
|
||||
nodes, 1 Compute node)
|
||||
|
||||
.. Install_Automatic:
|
||||
|
||||
Automatic Mode
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
When you unpack the scripts, you will see the following important files and
|
||||
folders:
|
||||
|
||||
`iso`
|
||||
This folder needs to contain a single ISO image for Fuel. Once you
|
||||
downloaded ISO from the portal, copy or move it into this directory.
|
||||
|
||||
`config.sh`
|
||||
This file contains configuration, which can be fine-tuned. For example, you
|
||||
can select how many virtual nodes to launch, as well as how much memory to give them.
|
||||
|
||||
`launch.sh`
|
||||
Once executed, this script will pick up an image from the ``iso`` directory,
|
||||
create a VM, mount the image to this VM, and automatically install the Fuel
|
||||
Master Тode.
|
||||
After installation of the master node, the script will create slave nodes for
|
||||
OpenStack and boot them via PXE from the Master Node.
|
||||
Finally, the script will give you the link to access the Web-based UI for the
|
||||
Master Node so you can start installation of an OpenStack cluster.
|
||||
|
||||
Here is the example configuration file, with the values that you can adjust:
|
||||
|
||||
.. literalinclude:: /_static/config.sh
|
||||
:language: bash
|
||||
|
||||
.. _Manual_Mode:
|
||||
|
||||
Manual mode
|
||||
^^^^^^^^^^^
|
||||
|
||||
If you cannot or would rather not run our helper scripts, you can still run
|
||||
Fuel on VirtualBox by following these steps.
|
||||
|
||||
.. note::
|
||||
|
||||
However, these manual steps will allow you to set up the evaluation environment
|
||||
for vanilla OpenStack release only. `RHOS installation is not possible.`
|
||||
|
||||
To download and deploy RedHat OpenStack you need to use automated VirtualBox
|
||||
helper scripts or install Fuel :ref:`Install_Bare-Metal`.
|
||||
|
||||
Master Node deployment
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
First, create the Master Node VM.
|
||||
|
||||
1. Configure the host-only interface vboxnet0 in VirtualBox.
|
||||
|
||||
* IP address: 10.20.0.1
|
||||
* Interface mask: 255.255.255.0
|
||||
* DHCP disabled
|
||||
|
||||
2. Create a VM for the master node with the following parameters:
|
||||
|
||||
* OS Type: Linux, Version: Red Hat (64bit)
|
||||
* RAM: 1024 MB
|
||||
* HDD: 20 GB, with dynamic disk expansion
|
||||
* CDROM: mount Fuel ISO
|
||||
* Network 1: host-only interface vboxnet0
|
||||
|
||||
3. Power on the VM in order to start the installation.
|
||||
|
||||
4. Wait for the Welcome message with all information needed to login into the UI
|
||||
of Fuel.
|
||||
|
||||
Adding Slave Nodes
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Next, create Slave nodes where OpenStack needs to be installed.
|
||||
|
||||
1. Create 3 or 4 additional VMs depending on your wish with the following parameters:
|
||||
|
||||
* OS Type: Linux, Version: Red Hat (64bit)
|
||||
* RAM: 1024 MB
|
||||
* HDD: 30 GB, with dynamic disk expansion
|
||||
* Network 1: host-only interface vboxnet0, PCnet-FAST III device
|
||||
|
||||
2. Set priority for the network boot:
|
||||
|
||||
.. image:: /_images/vbox-image1.png
|
||||
|
||||
3. Configure the network adapter on each VM:
|
||||
|
||||
.. image:: /_images/vbox-image2.png
|
||||
|
||||
Changing network parameters before the installation
|
||||
---------------------------------------------------
|
||||
|
||||
You can change the network settings for the admin (PXE booting) network, which
|
||||
is ``10.20.0.2/24 gw 10.20.0.1`` by default.
|
||||
|
||||
In order to do so, press the <TAB> key on the very first installation screen
|
||||
which says "Welcome to Fuel Installer!" and update the kernel options. For
|
||||
example, to use 192.168.1.10/24 IP address for the Master Node and 192.168.1.1
|
||||
as the gateway and DNS server you should change the parameters to those shown
|
||||
in the image below:
|
||||
|
||||
.. image:: /_images/network-at-boot.png
|
||||
|
||||
When you're finished making changes, press the <ENTER> key and wait for the
|
||||
installation to complete.
|
||||
|
||||
Changing network parameters after installation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. warning::
|
||||
|
||||
Once IP settings are set at the boot time for Fuel Master Node, they
|
||||
**should not be changed during the whole lifecycle of Fuel.**
|
||||
|
||||
It is still possible to configure other interfaces, or add 802.1Q sub-interfaces
|
||||
to the Master Node to be able to access it from your network if required.
|
||||
It is easy to do via standard network configuration scripts for CentOS. When the
|
||||
installation is complete, you can modify
|
||||
``/etc/sysconfig/network-scripts/ifcfg-eth\*`` scripts. For example, if *eth1*
|
||||
interface is on the L2 network which is planned for PXE booting, and *eth2* is
|
||||
the interface connected to your office network switch, *eth0* is not in use, then
|
||||
settings can be the following:
|
||||
|
||||
/etc/sysconfig/network-scripts/ifcfg-eth0::
|
||||
|
||||
DEVICE=eth0
|
||||
ONBOOT=no
|
||||
|
||||
/etc/sysconfig/network-scripts/ifcfg-eth1::
|
||||
|
||||
DEVICE=eth1
|
||||
ONBOOT=yes
|
||||
HWADDR=<your MAC>
|
||||
..... (other settings in your config) .....
|
||||
PEERDNS=no
|
||||
BOOTPROTO=static
|
||||
IPADDR=192.168.1.10
|
||||
NETMASK=255.255.255.0
|
||||
|
||||
/etc/sysconfig/network-scripts/ifcfg-eth2::
|
||||
|
||||
DEVICE=eth2
|
||||
ONBOOT=yes
|
||||
HWADDR=<your MAC>
|
||||
..... (other settings in your config) .....
|
||||
PEERDNS=no
|
||||
IPADDR=172.18.0.5
|
||||
NETMASK=255.255.255.0
|
||||
|
||||
After modification of network configuration files, it is required to apply the
|
||||
new configuration::
|
||||
|
||||
service network restart
|
||||
|
||||
Now you should be able to connect to Fuel UI from your network at
|
||||
http://172.18.0.5:8000/
|
||||
|
||||
Name resolution (DNS)
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
During Master Node installation, it is assumed that there is a recursive DNS
|
||||
service on 10.20.0.1.
|
||||
|
||||
If you want to make it possible for Slave nodes to be able to resolve public names,
|
||||
you need to change this default value to point to an actual DNS service.
|
||||
To make the change, run the following command on Fuel Master node (replace IP to
|
||||
your actual DNS)::
|
||||
|
||||
echo "nameserver 172.0.0.1" > /etc/dnsmasq.upstream
|
||||
|
||||
PXE booting settings
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By default, `eth0` on Fuel Master node serves PXE requests. If you are planning
|
||||
to use another interface, then it is required to modify dnsmasq settings (which
|
||||
acts as DHCP server). Edit the file ``/etc/cobbler/dnsmasq.template``, find the line
|
||||
``"interface=eth0"`` and replace the interface name with the one you want to use.
|
||||
|
||||
Launch command to synchronize cobbler service afterwards::
|
||||
|
||||
cobbler sync
|
||||
|
||||
During synchronization cobbler builds actual dnsmasq configuration file
|
||||
``/etc/dnsmasq.conf`` from template ``/etc/cobbler/dnsmasq.template``. That is
|
||||
why you should not edit ``/etc/dnsmasq.conf``. Cobbler rewrites it each time
|
||||
when it is synchronized.
|
||||
|
||||
If you want to use virtual machines to launch Fuel then you have to be sure
|
||||
that dnsmasq on master node is configured to support the PXE client you use on your
|
||||
virtual machines. We enabled *dhcp-no-override* option because without it
|
||||
dnsmasq tries to move ``PXE filename`` and ``PXE servername`` special fields
|
||||
into DHCP options. Not all PXE implementations can recognize those options and
|
||||
therefore they will not be able to boot. For example, CentOS 6.4 uses gPXE
|
||||
implementation instead of more advanced iPXE by default.
|
||||
|
||||
When Master Node installation is done
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once the Master node is installed, power on all other nodes and log in to the
|
||||
Fuel UI.
|
||||
|
||||
Slave nodes will be booted in bootstrap mode (CentOS based Linux in memory) via
|
||||
PXE and you will see notifications in the user interface about discovered nodes.
|
||||
This is the point when you can create an environment, add nodes into it, and
|
||||
start configuration...
|
||||
|
||||
Networking configuration is most complicated part, so please read the networking
|
||||
section of documentation carefully.
|
||||
|
|
@ -3,31 +3,38 @@ Network Issues
|
|||
|
||||
.. contents:: :local:
|
||||
|
||||
FuelWeb has built-in capability to run network check before or after OpenStack deployment. Currently it can check
|
||||
connectivity between nodes within configured VLANs on configured server interfaces. Image below shows sample
|
||||
result of such check. By using this simple table it is easy to say which interfaces do not receive certain VLAN IDs.
|
||||
Usually it measn that switch or multiple switches are not configured correctly and do not allow certain tagged
|
||||
traffic to pass through.
|
||||
Fuel has built-in capability to run network check before or after OpenStack
|
||||
deployment. Currently it can check connectivity between nodes within
|
||||
configured VLANs on configured server interfaces. Image below shows sample
|
||||
result of such check. By using this simple table it is easy to say which
|
||||
interfaces do not receive certain VLAN IDs. Usually it means that switch or
|
||||
multiple switches are not configured correctly and do not allow certain
|
||||
tagged traffic to pass through.
|
||||
|
||||
.. image:: /_images/net_verify_failure.png
|
||||
:width: 100%
|
||||
.. fancybox:: /_images/net_verify_failure.png
|
||||
:width: 600px
|
||||
:height: 200px
|
||||
|
||||
On VirtualBox
|
||||
-------------
|
||||
|
||||
Scripts which are provided for quick FuelWeb setup, create 3 host-interface adapters. Basically
|
||||
networking works as this being a 3 bridges, in each of them the only one VMs interfaces is connected.
|
||||
It means there is only L2 connectivity between VMs on interfaces named by the same name.
|
||||
If you try to move, for example, management network to eth1 on controller node, and the same network
|
||||
to eth2 on the compute, then there will be no connectivity between OpenStack services in spite of being
|
||||
configured to live on the same VLAN.
|
||||
It easy to validate settings before deploy by clicking on "Verify Networks" button before deployment.
|
||||
Scripts which are provided for quick Fuel setup, create 3 host-interface
|
||||
adapters. Basically networking works as this being a 3 bridges, in each of
|
||||
them the only one VMs interfaces is connected. It means there is only L2
|
||||
connectivity between VMs on interfaces with the same name. If you try to
|
||||
move, for example, management network to eth1 on controller node, and the
|
||||
same network to eth2 on the compute, then there will be no connectivity
|
||||
between OpenStack services in spite of being configured to live on the same
|
||||
VLAN. It is very easy to validate network settings before deployment by
|
||||
clicking the "Verify Networks" button.
|
||||
|
||||
Timeout in connection to OpenStack API from client applications
|
||||
---------------------------------------------------------------
|
||||
|
||||
If you use Java, Python or any other code to work with OpenStack API, all connections should be done over OpenStack public network.
|
||||
To explain why we can not use FuelWeb admin network, let's try to run nova client with debug option enabled::
|
||||
If you use Java, Python or any other code to work with OpenStack API, all
|
||||
connections should be done over OpenStack public network. To explain why we
|
||||
can not use Fuel admin network, let's try to run nova client with debug
|
||||
option enabled::
|
||||
|
||||
[root@controller-6 ~]# nova --debug list
|
||||
|
||||
|
|
@ -43,7 +50,10 @@ To explain why we can not use FuelWeb admin network, let's try to run nova clien
|
|||
|
||||
INFO (connectionpool:191) Starting new HTTP connection (1): 240.0.1.5
|
||||
|
||||
Even though initial connection was in 192.168.0.5, then client tries to access public network for Nova API. The reason is because Keystone
|
||||
returns the list of OpenStack services URLs, and for production-grade deployments it is required to access services over public network.
|
||||
If you still need to work with OpenStack API without routing configured, tell us your use case on IRC channel **#openstack-fuel** (on freenode) and
|
||||
we might be able to figure it out together.
|
||||
Even though initial connection was in 192.168.0.5, then client tries to
|
||||
access public network for Nova API. The reason is because Keystone returns
|
||||
the list of OpenStack services URLs, and for production-grade deployments it
|
||||
is required to access services over public network. If you still need to
|
||||
work with OpenStack API without routing configured, tell us your use case on
|
||||
IRC channel **#openstack-fuel** (on freenode) and we might be able to figure
|
||||
it out together.
|
||||
|
|
@ -4,14 +4,15 @@ Understanding and configuring the network
|
|||
.. contents:: :local:
|
||||
|
||||
OpenStack clusters use several types of network managers: FlatDHCPManager,
|
||||
VlanManager and Neutron (formerly Quantum).
|
||||
The current version of FuelWeb supports only the first two (FlatDHCP and
|
||||
VlanManager), but the FUEL library supports all three.
|
||||
For more information about how the first two network managers work, you can read
|
||||
these two resources:
|
||||
VlanManager and Neutron (formerly Quantum). The current version of Fuel UI
|
||||
supports only two (FlatDHCP and VlanManager), but Fuel CLI supports all
|
||||
three. For more information about how the first two network managers work,
|
||||
you can read these two resources:
|
||||
|
||||
* `OpenStack Networking – FlatManager and FlatDHCPManager <http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/>`_
|
||||
* `Openstack Networking for Scalability and Multi-tenancy with VlanManager <http://www.mirantis.com/blog/openstack-networking-vlanmanager/>`_
|
||||
* `OpenStack Networking – FlatManager and FlatDHCPManager
|
||||
<http://www.mirantis.com/blog/openstack-networking-flatmanager-and-flatdhcpmanager/>`_
|
||||
* `Openstack Networking for Scalability and Multi-tenancy with VlanManager
|
||||
<http://www.mirantis.com/blog/openstack-networking-vlanmanager/>`_
|
||||
|
||||
|
||||
FlatDHCPManager (multi-host scheme)
|
||||
|
|
@ -71,19 +72,18 @@ interface is the management network interface.
|
|||
compute2_eth0 .up. [L2 switch]
|
||||
compute3_eth0 .up. [L2 switch]
|
||||
|
||||
FuelWeb deploys OpenStack in FlatDHCP mode with the so called **multi-host**
|
||||
feature enabled.
|
||||
Without this feature enabled, network traffic from each VM would go through the
|
||||
single gateway host, which basically becomes a single point of failure. In
|
||||
enabled mode, each compute node becomes a gateway for all the VMs running on the
|
||||
host, providing a balanced networking solution.
|
||||
Fuel deploys OpenStack in FlatDHCP mode with the so called **multi-host**
|
||||
feature enabled. Without this feature enabled, network traffic from each VM
|
||||
would go through the single gateway host, which basically becomes a single
|
||||
point of failure. In enabled mode, each compute node becomes a gateway for
|
||||
all the VMs running on the host, providing a balanced networking solution.
|
||||
In this case, if one of the computes goes down, the rest of the environment
|
||||
remains operational.
|
||||
|
||||
The current version of FuelWeb uses VLANs, even for the FlatDHCP network manager.
|
||||
On the Linux host, it is implemented in such a way that it is not the physical
|
||||
network interfaces that are connected to the bridge, but the VLAN interface
|
||||
(i.e. **eth0.102**).
|
||||
The current version of Fuel uses VLANs, even for the FlatDHCP network
|
||||
manager. On the Linux host, it is implemented in such a way that it is not
|
||||
the physical network interfaces that are connected to the bridge, but the
|
||||
VLAN interface (i.e. **eth0.102**).
|
||||
|
||||
FlatDHCPManager (single-interface scheme)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -128,24 +128,24 @@ FlatDHCPManager (single-interface scheme)
|
|||
compute1_eth0 -up- [L2 switch]
|
||||
compute2_eth0 -up- [L2 switch]
|
||||
|
||||
Therefore all switch ports where compute nodes are connected must be configured
|
||||
as tagged (trunk) ports with required vlans allowed (enabled, tagged). Virtual
|
||||
machines will communicate with each other on L2 even if they are on different
|
||||
compute nodes. If the virtual machine sends IP packets to a different network,
|
||||
they will be routed on the host machine according to the routing table. The
|
||||
default route will point to the gateway specified on the networks tab in the UI
|
||||
as the gateway for the public network.
|
||||
Therefore all switch ports where compute nodes are connected must be
|
||||
configured as tagged (trunk) ports with required vlans allowed (enabled,
|
||||
tagged). Virtual machines will communicate with each other on L2 even if
|
||||
they are on different compute nodes. If the virtual machine sends IP packets
|
||||
to a different network, they will be routed on the host machine according to
|
||||
the routing table. The default route will point to the gateway specified on
|
||||
the networks tab in the UI as the gateway for the public network.
|
||||
|
||||
VLANManager
|
||||
------------
|
||||
|
||||
VLANManager mode is more suitable for large scale clouds. The idea behind this
|
||||
mode is to separate groups of virtual machines, owned by different projects, on
|
||||
different L2 layers. In VLANManager this is done by tagging IP frames, or simply
|
||||
speaking, by VLANs. It allows virtual machines inside the given project
|
||||
to communicate with each other and not to see any traffic from VMs of other
|
||||
projects. Switch ports must be configured as tagged (trunk) ports to allow this
|
||||
scheme to work.
|
||||
VLANManager mode is more suitable for large scale clouds. The idea behind
|
||||
this mode is to separate groups of virtual machines, owned by different
|
||||
projects, on different L2 layers. In VLANManager this is done by tagging IP
|
||||
frames, or simply speaking, by VLANs. It allows virtual machines inside the
|
||||
given project to communicate with each other and not to see any traffic from
|
||||
VMs of other projects. Switch ports must be configured as tagged (trunk)
|
||||
ports to allow this scheme to work.
|
||||
|
||||
.. uml::
|
||||
node "Compute1 Node" {
|
||||
|
|
@ -195,15 +195,15 @@ scheme to work.
|
|||
compute1_eth0 -up- [L2 switch]
|
||||
compute2_eth0 -up- [L2 switch]
|
||||
|
||||
FuelWeb deployment schema
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Fuel deployment schema
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
One of the physical interfaces on each host has to be chosen to carry VM-to-VM
|
||||
traffic (fixed network), and switch ports must be configured to allow tagged traffic
|
||||
to pass through. OpenStack Computes will untag the IP packets and send them to
|
||||
the appropriate VMs.
|
||||
Simplifying the configuration of VLAN Manager, there is no known limitation
|
||||
which FuelWeb could add in this particular networking mode.
|
||||
One of the physical interfaces on each host has to be chosen to carry
|
||||
VM-to-VM traffic (fixed network), and switch ports must be configured to
|
||||
allow tagged traffic to pass through. OpenStack Computes will untag the IP
|
||||
packets and send them to the appropriate VMs. Simplifying the configuration
|
||||
of VLAN Manager, there is no known limitation which Fuel could add in this
|
||||
particular networking mode.
|
||||
|
||||
Configuring the network
|
||||
-----------------------
|
||||
|
|
@ -214,9 +214,9 @@ accordingly. The diagram below shows an example configuration.
|
|||
.. image:: /_images/physical_sample.png
|
||||
:width: 100%
|
||||
|
||||
FuelWeb operates with following logical networks:
|
||||
Fuel operates with following logical networks:
|
||||
|
||||
* **FuelWeb** network is used for internal FuelWeb communications only and PXE
|
||||
* **Fuel** network is used for internal Fuel communications only and PXE
|
||||
booting (untagged on the scheme);
|
||||
* **Public** network is used to get access from virtual machines to outside,
|
||||
Internet or office network (vlan 101 on the scheme);
|
||||
|
|
@ -231,18 +231,19 @@ FuelWeb operates with following logical networks:
|
|||
Mapping logical networks to physical interfaces on servers
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
FuelWeb allows you to use different physical interfaces to handle different
|
||||
Fuel allows you to use different physical interfaces to handle different
|
||||
types of traffic. When a node is added to the environment, click at the bottom
|
||||
line of the node icon. In the detailed information window, click the "Network
|
||||
Configuration" button to open the physical interfaces configuration screen.
|
||||
|
||||
.. image:: /_images/doc_network-settings-help.png
|
||||
:width: 100%
|
||||
.. fancybox:: /_images/doc_network-settings-help.png
|
||||
:width: 600px
|
||||
:height: 600px
|
||||
|
||||
On this screen you can drag-and-drop logical networks to physical interfaces
|
||||
according to your network setup.
|
||||
|
||||
All networks are presented on the screen, except **fuelweb**.
|
||||
All networks are presented on the screen, except **Fuel**.
|
||||
It runs on the physical interface from which node was initially PXE booted,
|
||||
and in the current version it is not possible to map it on any other physical
|
||||
interface. Also, once the network is configured and OpenStack is deployed,
|
||||
|
|
@ -252,66 +253,70 @@ physical interface or VLAN number.
|
|||
Switch
|
||||
^^^^^^
|
||||
|
||||
FuelWeb can configure hosts, however switch configuration is still manual work.
|
||||
Unfortunately the set of configuration steps, and even the terminology used, is
|
||||
different for different vendors, so we will try to provide vendor-agnostic
|
||||
information on how traffic should flow and leave the vendor-specific details to
|
||||
you. We will provide an example for a Cisco switch.
|
||||
Fuel can configure hosts, however switch configuration is still manual work.
|
||||
Unfortunately the set of configuration steps, and even the terminology used,
|
||||
is different for different vendors, so we will try to provide
|
||||
vendor-agnostic information on how traffic should flow and leave the
|
||||
vendor-specific details to you. We will provide an example for a Cisco switch.
|
||||
|
||||
First of all, you must configure access ports to allow non-tagged PXE booting
|
||||
connections from all slave nodes to the FuelWeb node. We refer this network
|
||||
as the "admin" network, or "fuelweb".
|
||||
By default, the FuelWeb master node uses the ``eth0`` interface to serve PXE
|
||||
as the "Admin" network, or "Fuel".
|
||||
By default, the Fuel Master node uses the ``eth0`` interface to serve PXE
|
||||
First of all, you should configure access ports to allow non-tagged PXE booting
|
||||
connections from all slave nodes to the Fuel node. We refer this network
|
||||
as the "Admin" network, or "Fuel" network.
|
||||
By default, the Fuel Master node uses the ``eth0`` interface to serve PXE
|
||||
requests on this network.
|
||||
So if that's left unchanged, you must set the switch port for eth0 of FuelWeb to
|
||||
access mode.
|
||||
So if that's left unchanged, you have to set the switch port for eth0 of Fuel
|
||||
Master node to access mode.
|
||||
We recommend that you use the eth0 interfaces of all other nodes for PXE booting
|
||||
as well. Corresponding ports must also be in access mode.
|
||||
|
||||
Taking into account that this is the network for PXE booting, you must not mix
|
||||
this L2 segment with any other company infrastructure. FuelWeb runs a DHCP
|
||||
server, and if there is another company DHCP on the same L2, both the company's
|
||||
infrastructure and FuelWeb's will be unable to function properly.
|
||||
Taking into account that this is the network for PXE booting, do not mix
|
||||
this L2 segment with any other network segments. Fuel runs a DHCP
|
||||
server, and if there is another DHCP on the same L2 network segment, both the
|
||||
company's infrastructure and Fuel's will be unable to function properly.
|
||||
You also need to configure each of the switch's ports connected to nodes as an
|
||||
"STP Edge port" (or a "spanning-tree portfast trunk", according to Cisco
|
||||
"STP Edge port" (or a "spanning-tree port fast trunk", according to Cisco
|
||||
terminology). If you don't do that, DHCP timeout issues may occur.
|
||||
|
||||
As long as the "admin" network is configured, FuelWeb can operate.
|
||||
As long as the "Admin" network is configured, Fuel can operate.
|
||||
Other networks are required for OpenStack environments, and currently all of
|
||||
these networks live in VLANs over the one or multiple physical interfaces on a
|
||||
node. This means that the switch should pass tagged traffic, and untagging is done
|
||||
on the Linux hosts.
|
||||
|
||||
.. note::
|
||||
|
||||
For the sake of simplicity, all the VLANs specified on the networks tab of
|
||||
the FuelWeb should be configured on switch ports, pointing to slave nodes,
|
||||
as tagged.
|
||||
the Fuel UI should be configured on switch ports, pointing to Slave nodes,
|
||||
as tagged.
|
||||
|
||||
Of course, it is possible to specify as tagged only certain ports for a certain
|
||||
nodes. However, in the current version, all existing networks are automatically
|
||||
allocated for each node, with any role.
|
||||
And network check will also check if tagged traffic pass, even if some node does
|
||||
not require it (for example, Cinder nodes do not need fixed network traffic).
|
||||
And network check will also check if tagged traffic pass, even if some nodes do
|
||||
not require this check (for example, Cinder nodes do not need fixed network traffic).
|
||||
|
||||
This is enough to deploy the OpenStack environment. However, from a practical
|
||||
standpoint, it's still not really usable because there is no connection to other
|
||||
corporate networks yet. To make that possible, you must configure uplink port(s).
|
||||
This is enough to deploy the OpenStack environment. However, from a
|
||||
practical standpoint, it's still not really usable because there is no
|
||||
connection to other corporate networks yet. To make that possible, you must
|
||||
configure uplink port(s).
|
||||
|
||||
One of the VLANs may carry the office network. To provide access to the FuelWeb
|
||||
from the office network, any other free physical network interface on the
|
||||
FuelWeb master node can be used and configured according to the office network
|
||||
rules (static IP or DHCP). The same corporate network segment can be used for
|
||||
One of the VLANs may carry the office network. To provide access to the Fuel Master
|
||||
node from your network, any other free physical network interface on the
|
||||
Fuel Master node can be used and configured according to your network
|
||||
rules (static IP or DHCP). The same network segment can be used for
|
||||
public and floating ranges. In this case, you must provide the corresponding
|
||||
VLAN ID and IP ranges in the UI. One public IP per node will be used to SNAT
|
||||
traffic out of the VMs network, and one or more floating addresses per VM
|
||||
instance will be used to get access to the VM from the corporate network, or
|
||||
instance will be used to get access to the VM from your network, or
|
||||
even the global Internet. To have a VM visible from the Internet is similar to
|
||||
having it visible from corporate network - corresponding IP ranges and VLAN IDs
|
||||
must be specified for the floating and public networks. One current limitation
|
||||
of FuelWeb is that the user must use the same L2 segment for both public and
|
||||
of Fuel is that the user must use the same L2 segment for both public and
|
||||
floating networks.
|
||||
|
||||
Example configuration for one of the ports on a Cisco switch html::
|
||||
Example configuration for one of the ports on a Cisco switch::
|
||||
|
||||
interface GigabitEthernet0/6 # switch port
|
||||
description s0_eth0 jv # description
|
||||
|
|
@ -327,15 +332,15 @@ Router
|
|||
^^^^^^
|
||||
|
||||
To make it possible for VMs to access the outside world, you must have an IP
|
||||
address set on a router in the public network.
|
||||
In the examples provided, that IP is 12.0.0.1 in VLAN 101.
|
||||
address set on a router in the public network. In the examples provided,
|
||||
that IP is 12.0.0.1 in VLAN 101.
|
||||
|
||||
FuelWeb has a special field on the networking tab for the gateway address. As
|
||||
soon as deployment of OpenStack is started, the network on nodes is reconfigured
|
||||
to use this gateway IP as the default gateway.
|
||||
Fuel UI has a special field on the networking tab for the gateway address. As
|
||||
soon as deployment of OpenStack is started, the network on nodes is
|
||||
reconfigured to use this gateway IP as the default gateway.
|
||||
|
||||
If floating addresses are from another other L3 network, then you must set the
|
||||
IP (or even multiple IPs if floating addresses are from more than one L3
|
||||
If floating addresses are from another L3 network, then you have to configure the
|
||||
IP address (or even multiple IPs if floating addresses are from more than one L3
|
||||
network) for them on the router as well.
|
||||
|
||||
Otherwise, floating IPs on nodes will be inaccessible.
|
||||
|
|
@ -0,0 +1,469 @@
|
|||
.. _Post-Deployment-Check:
|
||||
|
||||
Post-Deployment Check
|
||||
=====================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
On occasion, even a successful deployment may result in some OpenStack
|
||||
components not working correctly. If this happens, Fuel offers the
|
||||
ability to perform post-deployment checks to verify operations. The goal of
|
||||
this functionality is to provide near real-time information on the status of
|
||||
the most commonly used components and the most recently performed actions.
|
||||
To perform these checks you will use Sanity and Smoke checks, as described
|
||||
below:
|
||||
|
||||
**Sanity Checks**
|
||||
Reveal whether the overall system is functional. If it fails, most likely you
|
||||
will need to restart some services to operate OpenStack.
|
||||
|
||||
**Smoke Checks**
|
||||
Give an understanding if something should be fixed relatively to specific
|
||||
OpenStack functions. Smoke checks reveal networking, system-requirements,
|
||||
functionality issues.
|
||||
|
||||
Sanity Checks will likely be the point on which the success of your
|
||||
deployment pivots, but it is critical to pay close attention to all information
|
||||
derived from theses tests. Another way to look at these tests is how they
|
||||
are named Sanity Checks are intended to assist in maintaining your sanity.
|
||||
Smoke Checks tell you where the fires are so you can put them out
|
||||
strategically instead of firehosing the entire installation.
|
||||
|
||||
Benefits
|
||||
--------
|
||||
|
||||
* Using post-deployment checks helps you identify potential issues which
|
||||
may impact the health of a deployed system.
|
||||
|
||||
* All post-deployment checks provide detailed description on failed operations
|
||||
and tell you which component or components are not working properly.
|
||||
|
||||
* Previously, performing these checks manually would have consumed a great deal
|
||||
of time. Now, with these checks the process will take only a few minutes.
|
||||
|
||||
* Aside from verifying that everything is working correctly, the process will
|
||||
also determine how quickly your system works.
|
||||
|
||||
* Post-deployment checks continue to be useful, for example after sizable
|
||||
changes are made in the system you can use the checks to determine if any
|
||||
new failure points have been introduced.
|
||||
|
||||
Running post-deployment checks
|
||||
------------------------------
|
||||
|
||||
Now, let`s take a closer look on what should be done to execute the tests and
|
||||
to understand if something is wrong with your OpenStack cluster.
|
||||
|
||||
.. image:: /_images/healthcheck_tab.png
|
||||
|
||||
As you can see on the image above, the Fuel UI now contains a ``Healthcheck``
|
||||
tab, indicated by the Heart icon.
|
||||
|
||||
All of the post-deployment checks are displayed on this tab. If your
|
||||
deployment was successful, you will see a list of tests this show a green
|
||||
Thumbs Up in the last column. The Thumb indicates the status of the
|
||||
component. If you see a detailed message and a Thumbs Down, that
|
||||
component has failed in some manner, and the details will indicate where the
|
||||
failure was detected. All tests can be run on different environments, which
|
||||
you select on main page of Fuel UI. You can run checks in parallel on
|
||||
different environments.
|
||||
|
||||
Each test contains information on its estimated and actual duration. We have
|
||||
included information about test processing time from our own tests and
|
||||
indicate this in each test. Note that we show average times from the slowest
|
||||
to the fastest systems we have tested, so your results will vary.
|
||||
|
||||
Once a test is complete the results will appear in the Status column. If
|
||||
there was an error during the test the UI will display the error message
|
||||
below the test name. To assist in the troubleshooting process, the test
|
||||
scenario is displayed under the failure message and the failed step is
|
||||
highlighted. You will find more detailed information on these tests later in
|
||||
this section.
|
||||
|
||||
An actual test run looks like this:
|
||||
|
||||
.. fancybox:: /_images/ostf_screen.png
|
||||
:width: 600px
|
||||
:height: 330px
|
||||
|
||||
What should be done when a test failed
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If a test failed, there are several ways to investigate the problem. You may
|
||||
prefer to start in Fuel UI since it's feedback is directly related to the
|
||||
health of the deployment. To do so, start by checking the following:
|
||||
|
||||
* Under the `Healthcheck` tab
|
||||
* In the OpenStack dashboard
|
||||
* In the test execution logs (/var/log/ostf-stdout.log)
|
||||
* In the individual OpenStack components logs
|
||||
|
||||
Of course, there are many different conditions that can lead to system
|
||||
breakdowns, but there are some simple things that can be examined before you
|
||||
dig deep. The most common issues are:
|
||||
|
||||
* Not all OpenStack services are running
|
||||
* Any defined quota has been exceeded
|
||||
* Something has broken in the network configuration
|
||||
* There is a general lack of resources (memory/disk space)
|
||||
|
||||
The first thing to be done is to ensure all OpenStack services are on. To do
|
||||
this you can run sanity test set, or execute the following command on your
|
||||
controller node::
|
||||
|
||||
nova-manage service list
|
||||
|
||||
If any service is off (has “XXX” status), you can restart it using this command::
|
||||
|
||||
service openstack-<service name> restart
|
||||
|
||||
If all services are on, but you`re still experiencing some issues, you can
|
||||
gather information on OpenStack Dashboard (exceeded number of instances,
|
||||
fixed IPs etc). You may also read the logs generated by tests which is
|
||||
stored at /var/log/ostf-stdout.log, or go to /var/log/<component> and view
|
||||
if any operation has ERROR status. If it looks like the last item, you may
|
||||
have underprovisioned your environment and should check your math and your
|
||||
project requirements.
|
||||
|
||||
Sanity tests description
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Sanity checks work by sending a query to all OpenStack components to get a
|
||||
response back from them. Many of these tests are simple in that they ask
|
||||
each service for a list of it's associated objects and waits for a response.
|
||||
The response can be something, nothing, and error, or a timeout, so there
|
||||
are several ways to determine if a service is up. The following list shows
|
||||
what test is used for each service:
|
||||
|
||||
.. topic:: Instances list availability
|
||||
|
||||
Test checks that Nova component can return list of instances.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of instances.
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Images list availability
|
||||
|
||||
Test checks that Glance component can return list of images.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of images.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Volumes list availability
|
||||
|
||||
Test checks that Swift component can return list of volumes.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of volumes.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Snapshots list availability
|
||||
|
||||
Test checks that Glance component can return list of snapshots.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of snapshots.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Flavors list availability
|
||||
|
||||
Test checks that Nova component can return list of flavors.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of flavors.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Limits list availability
|
||||
|
||||
Test checks that Nova component can return list of absolute limits.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of limits.
|
||||
|
||||
2. Check response.
|
||||
|
||||
.. topic:: Services list availability
|
||||
|
||||
Test checks that Nova component can return list of services.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of services.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: User list availability
|
||||
|
||||
Test checks that Keystone component can return list of users.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of services.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Services execution monitoring
|
||||
|
||||
Test checks that all of the expected services are on, meaning the test will
|
||||
fail if any of the listed services is in “XXX” status.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Connect to a controller via SSH.
|
||||
|
||||
2. Execute nova-manage service list command.
|
||||
|
||||
3. Check there are no failed services.
|
||||
|
||||
.. topic:: DNS availability
|
||||
|
||||
Test checks that DNS is available.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Connect to a controller node via SSH.
|
||||
|
||||
2. Execute host command for the controller IP.
|
||||
|
||||
3. Check DNS name can be successfully resolved.
|
||||
|
||||
.. topic:: Networks availability
|
||||
|
||||
Test checks that Nova component can return list of available networks.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of networks.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
.. topic:: Ports availability
|
||||
|
||||
Test checks that Nova component can return list of available ports.
|
||||
|
||||
Test scenario:
|
||||
|
||||
1. Request list of ports.
|
||||
|
||||
2. Check returned list is not empty.
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
Smoke tests description
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Smoke tests verify how your system handles basic OpenStack operations under
|
||||
normal circumstances. The Smoke test series uses timeout tests for
|
||||
operations that have a known completion time to determine if there is any
|
||||
smoke, and thusly fire. An additional benefit to the Smoke Test series is
|
||||
that you get to see how fast your environment is the first time you run them.
|
||||
|
||||
All tests use basic OpenStack services (Nova, Glance, Keystone, Cinder etc),
|
||||
therefore if any of them is off, the test using it will fail. It is
|
||||
recommended to run all sanity checks prior to your smoke checks to determine
|
||||
all services are alive. This helps ensure that you don't get any false
|
||||
negatives. The following is a description of each sanity test available:
|
||||
|
||||
.. topic:: Flavor creation
|
||||
|
||||
Test checks that low requirements flavor can be created.
|
||||
|
||||
Target component: Nova
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create small-size flavor.
|
||||
|
||||
2. Check created flavor has expected name.
|
||||
|
||||
3. Check flavor disk has expected size.
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
.. topic:: Volume creation
|
||||
|
||||
Test checks that a small-sized volume can be created.
|
||||
|
||||
Target component: Compute
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create a new small-size volume.
|
||||
|
||||
2. Wait for "available" volume status.
|
||||
|
||||
3. Check response contains "display_name" section.
|
||||
|
||||
4. Create instance and wait for "Active" status
|
||||
|
||||
5. Attach volume to instance.
|
||||
|
||||
6. Check volume status is "in use".
|
||||
|
||||
7. Get created volume information by its id.
|
||||
|
||||
8. Detach volume from instance.
|
||||
|
||||
9. Check volume has "available" status.
|
||||
|
||||
10. Delete volume.
|
||||
|
||||
If you see that created volume is in ERROR status, it can mean that you`ve
|
||||
exceeded the maximum number of volumes that can be created. You can check it
|
||||
on OpenStack dashboard. For more information refer to volume management
|
||||
instructions.
|
||||
|
||||
.. topic:: Instance booting and snapshotting
|
||||
|
||||
Test creates a keypair, checks that instance can be booted from default
|
||||
image, then a snapshot can be created from it and a new instance can be
|
||||
booted from a snapshot. Test also verifies that instances and images reach
|
||||
ACTIVE state upon their creation.
|
||||
|
||||
Target component: Glance
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create new keypair to boot an instance.
|
||||
|
||||
2. Boot default image.
|
||||
|
||||
3. Make snapshot of created server.
|
||||
|
||||
4. Boot another instance from created snapshot.
|
||||
|
||||
If you see that created instance is in ERROR status, it can mean that you`ve
|
||||
exceeded any system requirements limit. The test is using a nano-flavor with
|
||||
parameters: 64 RAM, 1 GB disk space, 1 virtual CPU presented. For more
|
||||
information refer to nova cli reference, image management instructions.
|
||||
|
||||
.. topic:: Keypair creation
|
||||
|
||||
Target component: Nova.
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create a new keypair, check if it was created successfully
|
||||
(check name is expected, response status is 200).
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
.. topic:: Security group creation
|
||||
|
||||
Target component: Nova
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create security group, check if it was created correctly
|
||||
(check name is expected, response status is 200).
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
.. topic:: Network parameters check
|
||||
|
||||
Target component: Nova
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Get list of networks.
|
||||
|
||||
2. Check seen network labels equal to expected ones.
|
||||
|
||||
3. Check seen network ids equal to expected ones.
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
.. topic:: Instance creation
|
||||
Target component: Nova
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create new keypair (if it`s nonexistent yet).
|
||||
|
||||
2. Create new sec group (if it`s nonexistent yet).
|
||||
|
||||
3. Create instance with usage of created sec group and keypair.
|
||||
|
||||
For more information refer to nova cli reference, instance management
|
||||
instructions.
|
||||
|
||||
.. topic:: Floating IP assignment
|
||||
|
||||
Target component: Nova
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create new keypair (if it`s nonexistent yet).
|
||||
|
||||
2. Create new sec group (if it`s nonexistent yet).
|
||||
|
||||
3. Create instance with usage of created sec group and keypair.
|
||||
|
||||
4. Create new floating ip.
|
||||
|
||||
5. Assign floating ip to created instance.
|
||||
|
||||
For more information refer to nova cli reference, floating ips management
|
||||
instructions.
|
||||
|
||||
.. topic:: Network connectivity check through floating IP
|
||||
|
||||
Target component: Nova
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create new keypair (if it`s nonexistent yet).
|
||||
|
||||
2. Create new sec group (if it`s nonexistent yet).
|
||||
|
||||
3. Create instance with usage of created sec group and keypair.
|
||||
|
||||
4. Check connectivity for all floating ips using ping command.
|
||||
|
||||
If this test failed, it`s better to run a network check and verify that all
|
||||
connections are correct. For more information refer to the Nova CLI reference's
|
||||
floating IPs management instructions.
|
||||
|
||||
.. topic:: User creation and authentication in Horizon
|
||||
|
||||
Test creates new user, tenant, user role with admin privileges and logs in
|
||||
to dashboard. Target components: Nova, Keystone
|
||||
|
||||
Scenario:
|
||||
|
||||
1. Create a new tenant.
|
||||
|
||||
2. Check tenant was created successfully.
|
||||
|
||||
3. Create a new user.
|
||||
|
||||
4. Check user was created successfully.
|
||||
|
||||
5. Create a new user role.
|
||||
|
||||
6. Check user role was created successfully.
|
||||
|
||||
7. Perform token authentication.
|
||||
|
||||
8. Check authentication was successful.
|
||||
|
||||
9. Send authentication request to Horizon.
|
||||
|
||||
10. Verify response status is 200.
|
||||
|
||||
If this test fails on the authentication step, you should first try opening
|
||||
the dashboard - it may be unreachable for some reason and then you should
|
||||
check your network configuration. For more information refer to nova cli
|
||||
reference.
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
Red Hat OpenStack Notes
|
||||
=======================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Fuel can deploy OpenStack using Red Hat OpenStack packages and Red Hat
|
||||
Enterprise Linux Server as a base operating system. Because Red Hat has
|
||||
exclusive distribution rights for its products, Fuel cannot be bundled with
|
||||
Red Hat OpenStack directly. To work around this issue, you can enter your
|
||||
Red Hat account credentials in order to download Red Hat OpenStack Platform.
|
||||
The necessary components will be prepared and loaded into Cobbler. There are
|
||||
two methods Fuel supports for obtaining Red Hat OpenStack packages:
|
||||
|
||||
* Red Hat Subscription Manager (RHSM)
|
||||
* and Red Hat RHN Satellite.
|
||||
|
||||
Minimal Requirements
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Red Hat account (https://access.redhat.com)
|
||||
* Red Hat OpenStack entitlement (one per host)
|
||||
* Internet access for Fuel master host
|
||||
|
||||
Optional requirements
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Red Hat Satellite Server
|
||||
* Configured Satellite activation key
|
||||
|
||||
Deployment types
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
* `Red Hat Subscription Management
|
||||
<https://access.redhat.com/site/articles/143253>`_ (default)
|
||||
* `Red Hat RHN
|
||||
Satellite <http://www.redhat.com/products/enterprise-linux/rhn-satellite/>`_
|
||||
|
||||
Red Hat Subscription Management overview
|
||||
----------------------------------------
|
||||
|
||||
Benefits
|
||||
^^^^^^^^
|
||||
|
||||
* No need to handle large ISOs or physical media.
|
||||
* Register all your clients with just a single username and password.
|
||||
* Automatically register the necessary products required for installation and
|
||||
downloads a full cache.
|
||||
* Download only the latest packages.
|
||||
* Download only necessary packages.
|
||||
|
||||
Considerations
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
* Must observe Red Hat licensing requirements after deployment
|
||||
* Package download time is dependent on network speed (20-60 minutes)
|
||||
|
||||
Red Hat RHN Satellite overview
|
||||
------------------------------
|
||||
|
||||
Benefits
|
||||
^^^^^^^^
|
||||
|
||||
* Faster download of Red Hat OpenStack packages
|
||||
* Register all your clients with an activation key
|
||||
* More granular control of package set for your installation
|
||||
* Registered OpenStack hosts don't need external network access
|
||||
* Easier to consume for large enterprise customers
|
||||
|
||||
Considerations
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
* Red Hat RHN Satellite is a separate offering from Red Hat and requires
|
||||
dedicated hardware
|
||||
* Still requires Red Hat Subscription Manager and Internet access to download
|
||||
registration packages (just for Fuel Master host)
|
||||
|
||||
What you need
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
* Red Hat account (https://access.redhat.com)
|
||||
* Red Hat OpenStack entitlement (one per host)
|
||||
* Internet access for Fuel master host
|
||||
* Red Hat Satellite Server
|
||||
* Configured Satellite activation key
|
||||
|
||||
Your RHN Satellite activation key must be configured the following channels
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* RHEL Server High Availability
|
||||
* RHEL Server Load Balancer
|
||||
* RHEL Server Optional
|
||||
* RHEL Server Resilient Storage
|
||||
* RHN Tools for RHEL
|
||||
* Red Hat OpenStack 3.0
|
||||
|
||||
.. _rhn_sat_channels:
|
||||
|
||||
Fuel looks for the following RHN Satellite channels.
|
||||
|
||||
* rhel-x86_64-server-6
|
||||
* rhel-x86_64-server-6-ost-3
|
||||
* rhel-x86_64-server-ha-6
|
||||
* rhel-x86_64-server-lb-6
|
||||
* rhel-x86_64-server-rs-6
|
||||
|
||||
.. note:: If you create cloned channels, leave these channel strings intact.
|
||||
|
||||
Troubleshooting
|
||||
---------------
|
||||
|
||||
Issues downloading from Red Hat Subscription Manager
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you receive an error from Fuel UI regarding Red Hat OpenStack download
|
||||
issues, ensure that you have a valid subscription to the Red Hat OpenStack
|
||||
3.0 product. This product is separate from standard Red Hat Enterprise
|
||||
Linux. You can check by going to https://access.redhat.com and checking
|
||||
Active Subscriptions. Contact your `Red Hat sales representative
|
||||
<https://access.redhat.com/site/solutions/368643>`_ to get the proper
|
||||
subscriptions associated with your account.
|
||||
|
||||
If you are still encountering issues, contact Mirantis Support.
|
||||
|
||||
Issues downloading from Red Hat RHN Satellite
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you receive an error from Fuel UI regarding Red Hat OpenStack download
|
||||
issues, ensure that you have all the necessary channels available on your
|
||||
RHN Satellite Server. The correct list is :ref:`here <rhn_sat_channels>`.
|
||||
|
||||
If you are missing these channels, please contact your `Red Hat sales
|
||||
representative <https://access.redhat.com/site/solutions/368643>`_ to get
|
||||
the proper subscriptions associated with your account.
|
||||
|
||||
RHN Satellite error: "rhel-x86_64-server-rs-6 not found"
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This means your Red Hat Satellite Server has run out of available entitlements
|
||||
or your licenses have expired. Check your RHN Satellite to ensure there is at
|
||||
least one available entitlement for each of the required channels.
|
||||
|
||||
If any of these channels are missing or you need to make changes your
|
||||
account, please contact your `Red Hat sales representative
|
||||
<https://access.redhat.com/site/solutions/368643>`_ to get the proper
|
||||
subscriptions associated with your account.
|
||||
|
||||
Yum Error: Cannot retrieve repository metadata (repomd.xml) for repository: rhel-x86_64-server-6.
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This can be caused by many problems. This could happen if your SSL
|
||||
certificate does not match the hostname of your RHN Satellite Server or if
|
||||
you configured Fuel to use an IP address during deployment. This is not
|
||||
recommended and you should use a fully qualified domain name for your RHN
|
||||
Satellite Server.
|
||||
|
||||
You may find solutions to your issues with repomd.xml at the
|
||||
`Red Hat Knowledgebase <https://access.redhat.com/>`_ or contact
|
||||
`Red Hat Support. <https://access.redhat.com/support/>`_.
|
||||
|
|
@ -1,263 +0,0 @@
|
|||
Installing FuelWeb
|
||||
------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
FuelWeb is distributed as both an ISO and an IMG image, each of which contains
|
||||
an installer for an admin node. The ISO image is used for CD media devices, iLO
|
||||
or similar remote access systems. The IMG file is used for USB memory drives.
|
||||
|
||||
Once installed, FuelWeb can be used to deploy and manage OpenStack clusters. It
|
||||
will assign IP addresses to the nodes, perform PXE boot and initial
|
||||
configuration, and provision of OpenStack nodes according to their roles in the
|
||||
cluster.
|
||||
|
||||
On Physical Hardware
|
||||
--------------------
|
||||
|
||||
To install FuelWeb on physical hardware, you need to burn the provided ISO to a
|
||||
CD/DVD, or IMG file to a USB stick, and start the installation process by
|
||||
booting from that media, very much like any other OS.
|
||||
|
||||
Linux and Mac users can prepare an installation USB stick with the ``dd``
|
||||
command. For example, if your flash drive is ``/dev/sdb``, you can use following
|
||||
command line::
|
||||
|
||||
dd if=fuelweb.img of=/dev/sdb
|
||||
|
||||
You can find the actual device name in the output of the ``dmesg`` command for
|
||||
Linux or ``diskutil list`` for Mac OS.
|
||||
|
||||
On Windows, you can write the installation image with
|
||||
`Win32 Disk Imager <http://sourceforge.net/projects/win32diskimager/>`_.
|
||||
|
||||
After the installation is complete, you will need to allocate physical nodes for
|
||||
your OpenStack cluster, put them on the same L2 network as the admin node, and
|
||||
PXE boot. The UI will discover them and make them available for installing
|
||||
OpenStack.
|
||||
|
||||
On VirtualBox
|
||||
-------------
|
||||
|
||||
If you are going to evaluate FuelWeb on VirtualBox, you should know that we
|
||||
provide a set of scripts that create and configure all of the required VMs for
|
||||
you, including the admin node and slave nodes for OpenStack itself. It's a very
|
||||
simple, single-click installation.
|
||||
|
||||
.. note::
|
||||
These scripts are not supported on Windows, but you can still test on
|
||||
VirtualBox by creating the VMs yourself. See "Manual Mode" for more
|
||||
information.
|
||||
|
||||
The requirements for running FuelWeb on VirtualBox are:
|
||||
|
||||
* A physical machine with Linux or Mac OS.
|
||||
|
||||
* The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, and Ubuntu 12.04.
|
||||
|
||||
* VirtualBox must be installed with the extension pack. Both can be downloaded
|
||||
from `<http://www.virtualbox.org/>`_.
|
||||
|
||||
* The scripts have been tested using VirtualBox 4.2.12
|
||||
|
||||
* 8 GB+ of RAM
|
||||
|
||||
* to handle 4 VMs for non-HA OpenStack installation (1 admin node, 1 controller
|
||||
node, 1 compute node, 1 cinder node)
|
||||
* to handle 5 VMs for HA OpenStack installation (1 admin node, 3 controller
|
||||
nodes, 1 compute node)
|
||||
|
||||
Automatic mode
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
When you unpack the scripts, you will see the following important files and folders:
|
||||
|
||||
* iso
|
||||
|
||||
* This folder needs to contain a single ISO image for FuelWeb. Once you
|
||||
download ISO from the portal, copy or move it into this directory
|
||||
|
||||
* config.sh
|
||||
|
||||
* This file contains configuration, which can be fine-tuned. For example, you
|
||||
can select how many virtual nodes to launch, as well as how much memory to give them.
|
||||
|
||||
* launch.sh
|
||||
|
||||
* Once executed, this script will pick up an image from the ``iso`` directory,
|
||||
create a VM, mount the image to this VM, and automatically install the admin
|
||||
node.
|
||||
* After installation of the admin node, the script creates slaves for OpenStack
|
||||
and PXE-boots them from the admin node.
|
||||
* Finally, the script gives you the link to access the Web-based UI for the
|
||||
admin node so you can start installation of an OpenStack cluster.
|
||||
|
||||
Here is the example config file, with the values that you can adjust:
|
||||
|
||||
.. literalinclude:: /../virtualbox/config.sh
|
||||
:language: bash
|
||||
:linenos:
|
||||
|
||||
Manual mode
|
||||
^^^^^^^^^^^
|
||||
|
||||
If you cannot or would rather not run the convenience scripts, you can still run
|
||||
FuelWeb on VirtualBox by following these steps.
|
||||
|
||||
Admin node deployment
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
First, create the admin node.
|
||||
|
||||
1. Configure the host-only interface vboxnet0 in VirtualBox.
|
||||
|
||||
* IP address: 10.20.0.1
|
||||
* Interface mask: 255.255.255.0
|
||||
* DHCP disabled
|
||||
|
||||
2. Create a VM for the admin node with the following parameters:
|
||||
|
||||
* OS Type: Linux, Version: Red Hat (64bit)
|
||||
* RAM: 1024 MB
|
||||
* HDD: 16 GB, with dynamic disk expansion
|
||||
* CDROM: mount iso installer
|
||||
* Network 1: host-ony interface vboxnet0
|
||||
|
||||
3. Power on the VM in order to start the installation.
|
||||
|
||||
4. Wait for the welcome message with all information needed to login into the UI
|
||||
of FuelWeb.
|
||||
|
||||
Adding slave nodes
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Next, create nodes on which to install OpenStack.
|
||||
|
||||
1. Create VMs with the following parameters:
|
||||
|
||||
* OS Type: Linux, Version: Red Hat (64bit)
|
||||
* RAM: 768 MB
|
||||
* HDD: 16 GB, with dynamic disk expansion
|
||||
* Network 1: host-only interface vboxnet0, PCnet-FAST III device
|
||||
|
||||
2. Set priority for the network boot:
|
||||
|
||||
.. image:: /_images/vbox-image1.png
|
||||
|
||||
3. Configure the network adapter on each VM:
|
||||
|
||||
.. image:: /_images/vbox-image2.png
|
||||
|
||||
Changing network parameters
|
||||
---------------------------
|
||||
|
||||
You can change the network settings for the admin (PXE booting) network, which
|
||||
is 10.20.0.2/24 gw 10.20.0.1 by default.
|
||||
|
||||
In order to do so, press the <TAB> key аt the very first installation screen
|
||||
which says "Welcome to FuelWeb Installer!" and update the kernel options. For
|
||||
example, to use 192.168.1.10/24 IP address for the master node and 192.168.1.1
|
||||
as the gateway and DNS server you should change the parameters to those shown
|
||||
in the image below:
|
||||
|
||||
.. image:: /_images/network-at-boot.png
|
||||
|
||||
When you're finished making changes, press the Enter key and wait for the
|
||||
installation to complete.
|
||||
|
||||
Changing network parameters after booting
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once IP settings are set at the boot time for FuelWeb master node, it **must not
|
||||
be changed during the whole lifecycle of FuelWeb.**
|
||||
It is still possible to configure other interfaces, or add 802.1Q subinterfaces
|
||||
to the FuelWeb to be able to access it from office network if required.
|
||||
It is easy to do via standard network configuration scripts for CentOS. When the
|
||||
installation is complete, you can modify
|
||||
``/etc/sysconfig/network-scripts/ifcfg-eth* `` scripts. For example, if *eth1*
|
||||
interface is on the L2 network which is planned for PXE booting, and *eth2* is
|
||||
the interface connected to office network switch, *eth0* is not in use, then
|
||||
settings can be the following:
|
||||
|
||||
/etc/sysconfig/network-scripts/ifcfg-eth0::
|
||||
|
||||
DEVICE=eth0
|
||||
ONBOOT=no
|
||||
|
||||
/etc/sysconfig/network-scripts/ifcfg-eth1::
|
||||
|
||||
DEVICE=eth1
|
||||
ONBOOT=yes
|
||||
HWADDR=<your MAC>
|
||||
..... (other settings in your config) .....
|
||||
PEERDNS=no
|
||||
BOOTPROTO=static
|
||||
IPADDR=192.168.1.10
|
||||
NETMASK=255.255.255.0
|
||||
|
||||
/etc/sysconfig/network-scripts/ifcfg-eth2::
|
||||
|
||||
DEVICE=eth2
|
||||
ONBOOT=yes
|
||||
HWADDR=<your MAC>
|
||||
..... (other settings in your config) .....
|
||||
PEERDNS=no
|
||||
IPADDR=172.18.0.5
|
||||
NETMASK=255.255.255.0
|
||||
|
||||
After modification of network configuration files, it is required to apply the
|
||||
new configuration::
|
||||
|
||||
service network restart
|
||||
|
||||
Now you should be able to connect to FuelWeb from the office network
|
||||
via `<http://172.18.0.5:8000/>`_
|
||||
|
||||
Name resolution (DNS)
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
During master node installation, it is assumed that there is a recursive DNS
|
||||
service on 10.20.0.1.
|
||||
|
||||
If you want to make it possible for slave nodes to be able to resolve public names,
|
||||
you need to change this default value to point to an actual DNS service.
|
||||
To make the change, run the following command on FuelWeb node (replace IP to
|
||||
your actual DNS)::
|
||||
|
||||
echo "nameserver 172.0.0.1" > /etc/dnsmasq.upstream
|
||||
|
||||
PXE booting settings
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
By default, eth0 on FuelWeb master node serves PXE requests. If you are planning
|
||||
to use another interface, then it is required to modify dnsmasq settings (which
|
||||
acts as DHCP server). Edit the file /etc/cobbler/dnsmasq.template, find the line
|
||||
``"interface=eth0"`` and replace the interface name with the one you want to use.
|
||||
Launch command to synchronize cobbler service afterwards::
|
||||
|
||||
cobbler sync
|
||||
|
||||
During synchronization cobbler builds actual dnsmasq configuration file
|
||||
``/etc/dnsmasq.conf`` from template ``/etc/cobbler/dnsmasq.template``. That is
|
||||
why you should not edit ``/etc/dnsmasq.conf``.
|
||||
Cobbler rewrites it each time when it is synchronized.
|
||||
|
||||
If you try to use virtual machines to launch **FuelWeb** then you have to be sure
|
||||
that dnsmasq on master node is configured to support that PXE client you use on your
|
||||
virtual machines. We enabled *dhcp-no-override* option because without it enabled
|
||||
dnsmasq tries to move out PXE filename and PXE servername special fields into DHCP options.
|
||||
Not all PXE implementations can understand those options and therefore they will not be
|
||||
able to boot. For example, Centos 6.3 uses gPXE implementation instead of more advanced
|
||||
iPXE by default.
|
||||
|
||||
When configuration is done
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once the master node is installed, power on all other nodes and open the FuelWeb on
|
||||
the configured network.
|
||||
Slave nodes will be booted in bootstrap mode (Centos based Linux in memory) via
|
||||
PXE and you will see notifications on the user interface about discovered nodes.
|
||||
This is the point when you can create an environment, add nodes into it, and
|
||||
start configuration.
|
||||
Networking configuration is most complicated part, so please read the networking
|
||||
section of documentation carefully.
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
In this section, you’ll learn how to install OpenStack using Fuel and FuelWeb.
|
||||
In addition to getting a feel for the steps involved, you’ll also gain valuable
|
||||
familiarity with some of the customization options. While Fuel provides different
|
||||
deployment configuration templates in the box, it is common for administrators
|
||||
to modify the architecture to meet enterprise requirements. Working hands on with
|
||||
Fuel for OpenStack will help you see how to move certain features around from the
|
||||
standard installation.
|
||||
|
||||
The first step, however, is to commit to a deployment template. A balanced,
|
||||
compact, and full-featured deployment is the Multi-node (HA) Compact deployment,
|
||||
so that’s what we’ll be using through the rest of this guide.
|
||||
|
||||
Production installations require a physical hardware infrastructure, but you can
|
||||
easily deploy a small simulation cloud on a single physical machine using VirtualBox.
|
||||
You can follow these instructions to install an OpenStack cloud into a test
|
||||
environment using VirtualBox, or to get a production-grade installation using
|
||||
physical hardware.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
|
||||
Before You Start
|
||||
----------------
|
||||
|
||||
Before you begin your installation, you will need to make a number of important decisions:
|
||||
|
||||
* **OpenStack features.** Your first decision is to decide which of the optional OpenStack features you will need. For example, you must decide whether you want to install Swift, whether you want Glance to use Swift for image storage, whether you want Cinder for block storage, and whether you want nova-network or Neutron (formerly Quantum) to handle your network connectivity. In our example installation we will be installing Glance with Swift support and Cinder for block storage. Also, due to the fact that it can be easily installed using orchestration, we will be using Neutron.
|
||||
|
||||
* **Deployment configuration.** Next, you need to decide whether your deployment requires high availability (HA). If you need HA for your deployment, you have a choice regarding the number of controllers you want to include. Following the recommendations in the previous section for a typical HA deployment configuration, we will use three OpenStack controllers.
|
||||
|
||||
* **Cobbler server and Puppet Master.** The heart of any Fuel install is the combination of Puppet Master and Cobbler used to create your resources. Although Cobbler and Puppet Master can be installed on separate machines, it is common practice to install both on a single machine for small to medium size clouds, and that's what we'll be doing in this example. By default, the Fuel ISO creates a single server with both services.
|
||||
|
||||
* **Domain name.** Puppet clients generate a Certificate Signing Request (CSR), which is then signed by the Puppet Master. The signed certificate can then be used to authenticate clients during provisioning. Certificate generation requires a fully qualified hostname, so you must choose a domain name to be used in your installation. Future versions of Fuel will enable you to choose this domain name on your own; by default, Fuel 3.1 uses ``localdomain``.
|
||||
|
||||
* **Network addresses.** OpenStack requires a minimum of three networks. If you are deploying on physical hardware, two of them -- the public network and the internal, or management network -- must be routable in your networking infrastructure. The third network is used by the nodes for inter-node communications. Also, if you intend for your cluster to be accessible from the Internet, you'll want the public network to be on the proper network segment. For simplicity in this case, this example assumes an Internet router at 192.168.0.1. Additionally, a set of private network addresses should be selected for automatic assignment to guest VMs. (These are fixed IPs for the private network). In our case, we are allocating network addresses as follows:
|
||||
|
||||
* Public network: 192.168.0.0/24
|
||||
* Internal network: 10.0.0.0/24
|
||||
* Private network: 10.0.1.0/24
|
||||
|
||||
* **Network interfaces.** All of those networks need to be assigned to the available NIC cards on the allocated machines. Additionally, if a fourth NIC is available, Cinder or block storage traffic can be separated and delegated to the fourth NIC. In our case, we're assigning networks as follows:
|
||||
|
||||
* Public network: eth1
|
||||
* Internal network: eth0
|
||||
* Private network: eth2
|
||||
|
||||
|
|
@ -1,203 +0,0 @@
|
|||
Infrastructure Allocation and Installation
|
||||
------------------------------------------
|
||||
|
||||
The next step is to make sure that you have all of the required hardware and software in place.
|
||||
|
||||
Software
|
||||
^^^^^^^^
|
||||
|
||||
You can download the latest release of the Fuel ISO from http://fuel.mirantis.com/your-downloads/.
|
||||
|
||||
Alternatively, if you can't use the pre-built ISO, Mirantis offers the Fuel Library as a tar.gz file downloadable from the `Downloads <http://fuel.mirantis.com/your-downloads/>`_ section of the Fuel portal. Using this file requires a bit more effort, but will yield the same results as using the ISO.
|
||||
|
||||
Network setup
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
OpenStack requires a minimum of three distinct networks: internal (or management), public, and private. The simplest and best methodology to map NICs is to assign each network to a different physical interface. However, not all machines have three NICs, and OpenStack can be configured and deployed with only two physical NICs, combining the internal and public traffic onto a single NIC.
|
||||
|
||||
If you are building a simulation environment, you are not limited to the availability of physical NICs. Allocate three NICs to each VM in your OpenStack infrastructure, one each for the internal, public, and private networks.
|
||||
|
||||
Finally, we assign network ranges to the internal, public, and private networks, and IP addresses to fuel-pm, fuel-controllers, and fuel-compute nodes. For deployment to a physical infrastructure you must work with your IT department to determine which IPs to use, but for the purposes of this exercise we will assume the below network and IP assignments:
|
||||
|
||||
#. 10.0.0.0/24: management or internal network, for communication between Puppet master and Puppet clients, as well as PXE/TFTP/DHCP for Cobbler.
|
||||
#. 192.168.0.0/24: public network, for the High Availability (HA) Virtual IP (VIP), as well as floating IPs assigned to OpenStack guest VMs
|
||||
#. 10.0.1.0/24: private network, fixed IPs automatically assigned to guest VMs by OpenStack upon their creation
|
||||
|
||||
Next we need to allocate a static IP address from the internal network to eth0 for fuel-pm, and eth1 for the controller, compute, and, if necessary, quantum nodes. For High Availability (HA) we must choose and assign an IP address from the public network to HAProxy running on the controllers. You can configure network addresses/network mask according to your needs, but our instructions assume the following network settings on the interfaces:
|
||||
|
||||
#. eth0: internal management network, where each machine is allocated a static IP address from a the defined pool of available addresses:
|
||||
|
||||
* 10.0.0.100 for Puppet Master
|
||||
* 10.0.0.101-10.0.0.103 for the controller nodes
|
||||
* 10.0.0.110-10.0.0.126 for the compute nodes
|
||||
* 10.0.0.10 internal Virtual IP for component access
|
||||
* 255.255.255.0 network mask
|
||||
|
||||
#. eth1: public network
|
||||
|
||||
* 192.168.0.10 public Virtual IP for access to the Horizon GUI (OpenStack management interface)
|
||||
|
||||
#. eth2: for communication between OpenStack VMs without IP address with promiscuous mode enabled.
|
||||
|
||||
Physical installation infrastructure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The hardware necessary for an installation depends on the choices you have made above. This sample installation requires the following hardware:
|
||||
|
||||
* 1 server to host both the Puppet Master and Cobbler. The minimum configuration for this server is:
|
||||
|
||||
* 32-bit or 64-bit architecture (64-bit recommended)
|
||||
* 1+ CPU or vCPU for up to 10 nodes (2 vCPU for up to 20 nodes, 4 vCPU for up to 100 nodes)
|
||||
* 1024+ MB of RAM for up to 10 nodes (4096+ MB for up to 20 nodes, 8192+ MB for up to 100 nodes)
|
||||
* 16+ GB of HDD for OS, and Linux distro storage
|
||||
|
||||
* 3 servers to act as OpenStack controllers (called fuel-controller-01, fuel-controller-02, and fuel-controller-03 for our sample deployment). The minimum configuration for a controller in Compact mode is:
|
||||
|
||||
* 64-bit architecture
|
||||
* 1+ CPU (2 or more CPUs or vCPUs recommended)
|
||||
* 1024+ MB of RAM (2048+ MB recommended)
|
||||
* 400+ GB of HDD
|
||||
|
||||
* 1 server to act as the OpenStack compute node (called fuel-compute-01). The minimum configuration for a compute node with Cinder installed is:
|
||||
|
||||
* 64-bit architecture
|
||||
* 2+ CPU, with Intel VTx or AMDV virtualization technology enabled
|
||||
* 2048+ MB of RAM
|
||||
* 1+ TB of HDD
|
||||
|
||||
If you choose to deploy Neutron (formerly Quantum) on a separate node, you will need an additional server with specifications comparable to the controller nodes.
|
||||
|
||||
Make sure your hardware is capable of PXE booting over the network from Cobbler. You'll also need each server's mac addresses.
|
||||
|
||||
For a list of certified hardware configurations, please `contact the Mirantis Services team <http://www.mirantis.com/contact/>`_.
|
||||
|
||||
Virtual installation infrastructure
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
For a virtual installation, you need only a single machine. You can get by on 8GB of RAM, but 16GB or more is recommended.
|
||||
|
||||
To perform the installation, you need a way to create Virtual Machines. This guide assumes that you are using version 4.2.12 or later of VirtualBox, which you can download from `the VirtualBox site <https://www.virtualbox.org/wiki/Downloads>`_. It is also required that you have the Extension Pack installed to enable features that are needed for a virtualized OpenStack test environment to work correctly.
|
||||
|
||||
You'll need to run VirtualBox on a stable host system. Mac OS 10.7.x, CentOS 6.3+, or Ubuntu 12.04 are preferred; results in other operating systems are unpredictable. It's also important to remember that Windows is incapable of running the installation scripts for Fuel so we cannot recommend Windows as a test platform.
|
||||
|
||||
Configuring VirtualBox
|
||||
++++++++++++++++++++++
|
||||
|
||||
If you are on VirtualBox, please create the following host-only adapters and that they are configured correctly:
|
||||
|
||||
* VirtualBox -> File -> Preferences...
|
||||
|
||||
* Network -> Add HostOnly Adapter (vboxnet0)
|
||||
|
||||
* IPv4 Address: 10.0.0.1
|
||||
* IPv4 Network Mask: 255.255.255.0
|
||||
* DHCP server: disabled
|
||||
|
||||
* Network -> Add HostOnly Adapter (vboxnet1)
|
||||
|
||||
* IPv4 Address: 10.0.1.1
|
||||
* IPv4 Network Mask: 255.255.255.0
|
||||
* DHCP server: disabled
|
||||
|
||||
* Network -> Add HostOnly Adapter (vboxnet2)
|
||||
|
||||
* IPv4 Address: 0.0.0.0
|
||||
* IPv4 Network Mask: 255.255.255.0
|
||||
* DHCP server: disabled
|
||||
|
||||
In this example, only the first two adapters will be used. If necessasry, though, you can choose to use the third adapter to handle your storage network traffic.
|
||||
|
||||
After creating these interfaces, reboot the host machine to make sure that DHCP isn't running in the background.
|
||||
|
||||
As stated before, installing on Windows isn't recommended, but if you're attempting to do so you will also need to set up the IP address & network mask under Control Panel > Network and Internet > Network and Sharing Center for the Virtual HostOnly Network adapter.
|
||||
|
||||
Creating fuel-pm
|
||||
++++++++++++++++
|
||||
|
||||
The process of creating a virtual machine to host Fuel in VirtualBox depends on whether your deployment is purely virtual or consists of a physical or virtual fuel-pm controlling physical hardware. If your deployment is purely virtual then Adapter 1 may be a Hostonly adapter attached to vboxnet0, but if your deployment infrastructure consists of a virtual fuel-pm controlling physical machines Adapter 1 must be a Bridged Adapter and connected to whatever network interface of the host machine is connected to your physical machines.
|
||||
|
||||
To create fuel-pm, start up VirtualBox and create a new machine as follows:
|
||||
|
||||
* Machine -> New...
|
||||
|
||||
* Name: fuel-pm
|
||||
* Type: Linux
|
||||
* Version: Red Hat (64 Bit)
|
||||
* Memory: 2048 MB
|
||||
* Drive space: 16 GB HDD
|
||||
|
||||
* Machine -> Settings... -> Network
|
||||
|
||||
* Adapter 1
|
||||
|
||||
* Physical network
|
||||
* Enable Network Adapter
|
||||
* Attached to: Bridged Adapter
|
||||
* Name: The host machine's network with access to the network on which the physical machines reside
|
||||
* VirtualBox installation
|
||||
* Enable Network Adapter
|
||||
* Attached to: Hostonly Adapter
|
||||
* Name: vboxnet0
|
||||
|
||||
* Adapter 2
|
||||
|
||||
* Enable Network Adapter
|
||||
* Attached to: Bridged Adapter
|
||||
* Name: eth0 (or whichever physical network is attached to the Internet)
|
||||
|
||||
* Machine -> Storage
|
||||
|
||||
* Attach the downloaded ISO as a drive
|
||||
|
||||
If you cannot or prefer not to install from the ISO, you can find instructions for installing from the Fuel Library in :ref:`Appendix A <Create-PM>`.
|
||||
|
||||
Creating the OpenStack nodes
|
||||
++++++++++++++++++++++++++++
|
||||
|
||||
If you're using VirtualBox, you will need to create the necessary virtual machines for your OpenStack nodes. Follow these instructions to create machines named fuel-controller-01, fuel-controller-02, fuel- controller-03, and fuel-compute-01. Please, do NOT start these virtual machines until instructed.
|
||||
|
||||
As you create each network adapter, click Advanced to expose and record the corresponding mac address.
|
||||
|
||||
* Machine -> New...
|
||||
|
||||
* Name: fuel-controller-01 (you will repeat these steps to create fuel-controller-02, fuel-controller-03, and fuel-compute-01)
|
||||
* Type: Linux
|
||||
* Version: Red Hat (64 Bit)
|
||||
* Memory: 2048MB
|
||||
* Drive space: 8GB
|
||||
|
||||
* Machine -> Settings -> System
|
||||
|
||||
* Check Network in Boot sequence
|
||||
|
||||
* Machine -> Settings -> Storage
|
||||
|
||||
* Controller: SATA
|
||||
|
||||
* Click the Add icon at the bottom of the Storage Tree pane and choose Add Disk
|
||||
* Add a second VDI disk of 10GB for storage
|
||||
|
||||
* Machine -> Settings -> Network
|
||||
|
||||
* Adapter 1
|
||||
|
||||
* Enable Network Adapter
|
||||
* Attached to: Hostonly Adapter
|
||||
* Name: vboxnet0
|
||||
|
||||
* Adapter 2
|
||||
|
||||
* Enable Network Adapter
|
||||
* Attached to: Bridged Adapter
|
||||
* Name: eth0 (physical network attached to the Internet. You may also use a gateway if necessary.)
|
||||
|
||||
* Adapter 3
|
||||
|
||||
* Enable Network Adapter
|
||||
* Attached to: Hostonly Adapter
|
||||
* Name: vboxnet1
|
||||
* Advanced -> Promiscuous mode: Allow All
|
||||
|
||||
It is important that Adapter 1 is configured to load first as Cobbler will use vboxnet0 for PXE and VirtualBox boots from the LAN using the first available network adapter.
|
||||
|
||||
The additional drive volume will be used as storage space by Cinder and will be configured automatically by Fuel.
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
Installing & Configuring Fuel
|
||||
-----------------------------
|
||||
|
||||
Having planned your test or production deployment and have determined the resources you will be using, it's time to begin putting the pieces together. To do that, you'll need to create the Puppet master and Cobbler servers, which will actually provision and configure your OpenStack nodes.
|
||||
|
||||
Installing the Puppet Master is a one-time procedure for the entire infrastructure. Once done, Puppet Master will act as a single point of management for all of your servers, and you will never have to return to these installation steps again.
|
||||
|
||||
The deployment of the Puppet Master server, named fuel-pm in these instructions, varies slightly between the physical and simulation environments. In a physical infrastructure, fuel-pm must have a network presence on the same network as the physical machines in order to faciliate PXE booting. In a simulation environment fuel-pm only needs host-only virtual network connectivity.
|
||||
|
||||
At this point, you should have either a physical or virtual machine that can be booted from the Mirantis ISO, downloaded from http://fuel.mirantis.com/your-downloads/.
|
||||
|
||||
This ISO can be used to create fuel-pm on a physical or virtual machine based on CentOS 6.4. If for some reason you cannot use the ISO, follow the instructions in :ref:`Creating the Puppet master <Create-PM>` to create your own fuel-pm, then skip ahead to :ref:`Configuring fuel-pm <Configuring-Fuel-PM>`.
|
||||
|
||||
Installing Fuel from the ISO
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Start the new machine to install the ISO. The only real installation decision you will need to make is to specify the interface through which the installer can access the Internet. Select the eth1 interface you created earlier which should be configured for access to the public network.
|
||||
|
||||
Configuring fuel-pm from the ISO installation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once fuel-pm finishes installing, you'll be presented with a basic menu. You can use this menu to set the basic information Fuel will need to configure your installation. You can customize these steps to suit your own need, of course, but here are the steps to take for the example installation:
|
||||
|
||||
#. Your admin node must be called ``fuel-pm``, and your domain name must be ``localdomain``.
|
||||
#. To configure the management interface, choose 2.
|
||||
|
||||
* The example specifies eth0 as the internal, or management interface, so select that interface.
|
||||
* The management network in the example is using static IP addresses, so specify NO for for using DHCP.
|
||||
* Enter the IP address of 10.0.0.100 for the Puppet Master with a netmask of 255.255.255.0.
|
||||
* Set the gateway and DNS servers if desired. In this example, we'll use the router at 192.168.0.1 as the gateway.
|
||||
|
||||
#. To configure the external interface that VMs will use to send traffic to and from the internet, choose 3. Set the interface to eth1. By default, this interface uses DHCP, which is what the example calls for.
|
||||
|
||||
#. To choose the start and end addresses to be used during PXE boot, choose 4. In the case of this example, the start address is 10.0.0.201 and the end address is 10.0.0.254. Later, these nodes will receive IP addresses from Cobbler.
|
||||
|
||||
#. Future versions of Fuel will enable you to choose a custom set of repositories.
|
||||
|
||||
#. If you need to specify a proxy through which fuel-pm will access the Internet, press 6.
|
||||
|
||||
#. Once you've finished editing, choose 9 to save your changes and exit the menu.
|
||||
|
||||
Please note: Even though defaults are shown, you must set actual values; if you simply press "enter" you will wind up with empty values.
|
||||
|
||||
To re-enter the menu at any time, type:
|
||||
|
||||
bootstrap_admin_node.sh
|
||||
|
|
@ -1,296 +0,0 @@
|
|||
.. _Install-OS-Using-Fuel:
|
||||
|
||||
Installing the OS using Fuel
|
||||
----------------------------
|
||||
|
||||
The first step to creating OpenStack nodes is to let Fuel's Cobbler kickstart and preseed files assist in the installation of operating systems on the target servers.
|
||||
|
||||
.. _Configuring-Cobbler:
|
||||
|
||||
Configuring Cobbler with config.yaml
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Fuel uses the ``config.yaml`` file to configure Cobbler and assist in the configuration of the ``site.pp`` file. This file appears in the ``/root`` directory when the master node (fuel-pm) is provisioned and configured.
|
||||
|
||||
You'll want to configure this example to meet your own needs, but the example looks like this::
|
||||
|
||||
common:
|
||||
orchestrator_common:
|
||||
attributes:
|
||||
deployment_mode: ha_compact
|
||||
deployment_engine: simplepuppet
|
||||
task_uuid: deployment_task
|
||||
|
||||
Possible values for ``deployment_mode`` are ``singlenode_compute``, ``multinode_compute``, ``ha_compute``, ``ha_compact``, ``ha_full``, and ``ha_minimal``. For this example, we will set the ``deployment_mode`` to ``ha_compact`` to tell Fuel to use HA architecture. Specifying the ``simplepuppet`` deployment engine means that the orchestrator will be calling Puppet on each of the nodes.
|
||||
|
||||
Next you'll need to set OpenStack's networking information::
|
||||
|
||||
openstack_common:
|
||||
internal_virtual_ip: 10.0.0.10
|
||||
public_virtual_ip: 192.168.0.10
|
||||
create_networks: true
|
||||
fixed_range: 172.16.0.0/16
|
||||
floating_range: 192.168.0.0/24
|
||||
|
||||
Change the virtual IPs to match the target networks, and set the fixed and floating ranges. ::
|
||||
|
||||
swift_loopback: loopback
|
||||
nv_physical_volumes:
|
||||
- /dev/sdb
|
||||
|
||||
By setting the ``nv_physical_volumes`` value, you are not only telling OpenStack to use this value for Cinder (you'll see more about that in the ``site.pp`` file), but also where Cinder should store its data.
|
||||
|
||||
Later, we'll set up a new partition for Cinder, so tell Cobbler to create it here. ::
|
||||
|
||||
external_ip_info:
|
||||
public_net_router: 192.168.0.1
|
||||
ext_bridge: 0.0.0.0
|
||||
pool_start: 192.168.0.110
|
||||
pool_end: 192.168.0.126
|
||||
|
||||
Set the ``public_net_router`` to point to the real router at the public network. The ``ext_bridge`` is the IP of the Neutron (formerly Quantum) bridge. It should assigned to any available free IP on the public network that's outside the floating range. You also have the option to simply set it to ``0.0.0.0``. The ``pool_start`` and ``pool_end`` values represent the public addresses of your nodes, and should be within the ``floating_range``. ::
|
||||
|
||||
segment_range: 900:999
|
||||
network_manager: nova.network.manager.FlatDHCPManager
|
||||
auto_assign_floating_ip: true
|
||||
quantum_netnode_on_cnt: true
|
||||
|
||||
Fuel provides two choices for your network manager: FlatDHCPManager, and VlanManager. By default, the system uses FlatDHCPManager. Here you can see that we're also telling OpenStack to automatically assing a floating IP to an instance when it's created, and to put the Neutron services on the controllers rather than a sepearate node.You can also choose ``tenant_network_type`` for network segmentation type and segmentation range ``segment_range`` for network (consult Neutron documentation for details). ::
|
||||
|
||||
use_syslog: false
|
||||
syslog_server: 127.0.0.1
|
||||
mirror_type: default
|
||||
|
||||
**THIS SETTING IS CRUCIAL:** The ``mirror_type`` **must** to be set to ``default`` unless you have your own repositories set up, or OpenStack will not install properly. ::
|
||||
|
||||
quantum: true
|
||||
internal_interface: eth0
|
||||
public_interface: eth1
|
||||
private_interface: eth2
|
||||
public_netmask: 255.255.255.0
|
||||
internal_netmask: 255.255.255.0
|
||||
|
||||
Earlier, you decided which interfaces to use for which networks; note that here. ::
|
||||
|
||||
default_gateway: 192.168.0.1
|
||||
|
||||
Depending on how you've set up your network, you can either set the ``default_gateway`` to the master node (fuel-pm) or to the ``public_net_router``. ::
|
||||
|
||||
nagios_master: fuel-controller-01.localdomain
|
||||
loopback: loopback
|
||||
cinder: true
|
||||
cinder_nodes:
|
||||
- controller
|
||||
swift: true
|
||||
|
||||
The loopback setting determines how Swift stores data. If you set the value to ``loopback``, Swift will use 1gb files as storage devices. If you tuned Cobbler to create a partition for Swift and mounted it to ``/srv/nodes/``, then you should set ``loopback`` to ``false``.
|
||||
|
||||
In this example, you're using Cinder and including it on the compute nodes, so note that appropriately. Also, you're using Swift, so turn that on here. ::
|
||||
|
||||
repo_proxy: http://10.0.0.100:3128
|
||||
|
||||
One improvement in Fuel 2.1 was the ability for the master node to cache downloads in order to speed up installs; by default the ``repo_proxy`` is set to point to fuel-pm in order to let that happen. One consequence of that is that your deployment will actually go faster if you let one install complete, then do all the others, rather than running all of them concurrently. ::
|
||||
|
||||
deployment_id: '53'
|
||||
|
||||
Fuel enables you to manage multiple clusters; setting the ``deployment_id`` will let Fuel know which deployment you're working with. ::
|
||||
|
||||
dns_nameservers:
|
||||
- 10.0.0.100
|
||||
- 8.8.8.8
|
||||
|
||||
The slave nodes should first look to the master node for DNS, so mark that as your first nameserver.
|
||||
|
||||
The next step is to define the nodes themselves. To do that, you'll list each node once for each role that needs to be installed. Note that by default the first node is called ``fuel-cobbler``; change it to ``fuel-pm``. ::
|
||||
|
||||
nodes:
|
||||
- name: fuel-pm
|
||||
role: cobbler
|
||||
internal_address: 10.0.0.100
|
||||
public_address: 192.168.0.100
|
||||
- name: fuel-controller-01
|
||||
role: controller
|
||||
internal_address: 10.0.0.101
|
||||
public_address: 192.168.0.101
|
||||
swift_zone: 1
|
||||
- name: fuel-controller-02
|
||||
role: controller
|
||||
internal_address: 10.0.0.102
|
||||
public_address: 192.168.0.102
|
||||
swift_zone: 2
|
||||
- name: fuel-controller-03
|
||||
role: controller
|
||||
internal_address: 10.0.0.103
|
||||
public_address: 192.168.0.103
|
||||
swift_zone: 3
|
||||
- name: fuel-controller-01
|
||||
role: quantum
|
||||
internal_address: 10.0.0.101
|
||||
public_address: 192.168.0.101
|
||||
- name: fuel-compute-01
|
||||
role: compute
|
||||
internal_address: 10.0.0.110
|
||||
public_address: 192.168.0.110
|
||||
|
||||
Notice that each node can be listed multiple times; this is because each node fulfills multiple roles. Notice also that the IP address for fuel-compute-01 is *.110, not *.105.
|
||||
|
||||
The ``cobbler_common`` section applies to all machines::
|
||||
|
||||
cobbler_common:
|
||||
# for Centos
|
||||
profile: "centos64_x86_64"
|
||||
# for Ubuntu
|
||||
# profile: "ubuntu_1204_x86_64"
|
||||
|
||||
Fuel can install CentOS or Ubuntu on your servers, or you can add a profile of your own. By default, ``config.yaml`` uses CentOS. ::
|
||||
|
||||
netboot-enabled: "1"
|
||||
# for Ubuntu
|
||||
# ksmeta: "puppet_version=2.7.19-1puppetlabs2 \
|
||||
# for Centos
|
||||
name-servers: "10.0.0.100"
|
||||
name-servers-search: "localdomain"
|
||||
gateway: 192.168.0.1
|
||||
|
||||
Set the default nameserver to be fuel-pm, and change the domain name to your own domain name. Set the ``gateway`` to the public network's default gateway. Alternatively, if you don't plan to use your public networks actual gateway, you can set this value to be the IP address of the master node.
|
||||
|
||||
**Please note:** You must specify a working gateway (or proxy) in order to install OpenStack, because the system will need to communicate with public repositories. ::
|
||||
|
||||
ksmeta: "puppet_version=2.7.19-1puppetlabs2 \
|
||||
puppet_auto_setup=1 \
|
||||
puppet_master=fuel-pm.localdomain \
|
||||
|
||||
Change the fully-qualified domain name for the Puppet Master to reflect your own domain name. ::
|
||||
|
||||
puppet_enable=0 \
|
||||
ntp_enable=1 \
|
||||
mco_auto_setup=1 \
|
||||
mco_pskey=un0aez2ei9eiGaequaey4loocohjuch4Ievu3shaeweeg5Uthi \
|
||||
mco_stomphost=10.0.0.100 \
|
||||
|
||||
Make sure the ``mco_stomphost`` is set for the master node so that the orchestrator can find the nodes. ::
|
||||
|
||||
mco_stompport=61613 \
|
||||
mco_stompuser=mcollective \
|
||||
mco_stomppassword=AeN5mi5thahz2Aiveexo \
|
||||
mco_enable=1"
|
||||
|
||||
This section sets the system up for orchestration; you shouldn't have to touch it.
|
||||
|
||||
Next you'll define the actual servers. ::
|
||||
|
||||
fuel-controller-01:
|
||||
hostname: "fuel-controller-01"
|
||||
role: controller
|
||||
interfaces:
|
||||
eth0:
|
||||
mac: "08:00:27:BD:3A:7D"
|
||||
static: "1"
|
||||
ip-address: "10.0.0.101"
|
||||
netmask: "255.255.255.0"
|
||||
dns-name: "fuel-controller-01.localdomain"
|
||||
management: "1"
|
||||
eth1:
|
||||
mac: "08:00:27:ED:9C:3C"
|
||||
static: "0"
|
||||
eth2:
|
||||
mac: "08:00:27:B0:EB:2C"
|
||||
static: "1"
|
||||
interfaces_extra:
|
||||
eth0:
|
||||
peerdns: "no"
|
||||
eth1:
|
||||
peerdns: "no"
|
||||
eth2:
|
||||
promisc: "yes"
|
||||
userctl: "yes"
|
||||
peerdns: "no"
|
||||
|
||||
For a VirtualBox installation, you can retrieve the MAC ids for your network adapters by expanding "Advanced" for the adapater in VirtualBox, or by executing ifconfig on the server itself.
|
||||
|
||||
For a physical installation, the MAC address of the server is often printed on the sticker attached to the server for the LOM interfaces, or is available from the BIOS screen. You may also be able to find the MAC address in the hardware inventory BMC/DRAC/ILO, though this may be server-dependent.
|
||||
|
||||
Also, make sure the ``ip-address`` is correct, and that the ``dns-name`` has your own domain name in it.
|
||||
|
||||
In this example, IP addresses should be assigned as follows::
|
||||
|
||||
fuel-controller-01: 10.0.0.101
|
||||
fuel-controller-02: 10.0.0.102
|
||||
fuel-controller-03: 10.0.0.103
|
||||
fuel-compute-01: 10.0.0.110
|
||||
|
||||
Repeat this step for each of the other controllers, and for the compute node. Note that the compute node has its own role::
|
||||
|
||||
fuel-compute-01:
|
||||
hostname: "fuel-compute-01"
|
||||
role: compute
|
||||
interfaces:
|
||||
eth0:
|
||||
mac: "08:00:27:AE:A9:6E"
|
||||
static: "1"
|
||||
ip-address: "10.0.0.110"
|
||||
netmask: "255.255.255.0"
|
||||
dns-name: "fuel-compute-01.localdomain"
|
||||
management: "1"
|
||||
eth1:
|
||||
mac: "08:00:27:B7:F9:CD"
|
||||
static: "0"
|
||||
eth2:
|
||||
mac: "08:00:27:8B:A6:B7"
|
||||
static: "1"
|
||||
interfaces_extra:
|
||||
eth0:
|
||||
peerdns: "no"
|
||||
eth1:
|
||||
peerdns: "no"
|
||||
eth2:
|
||||
promisc: "yes"
|
||||
userctl: "yes"
|
||||
peerdns: "no"
|
||||
|
||||
|
||||
Loading the configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Once you've completed the changes to ``config.yaml``, you need to load the information into Cobbler. To do that, use the ``cobbler_system`` script::
|
||||
|
||||
cobbler_system -f config.yaml
|
||||
|
||||
Now you're ready to start spinning up the controllers and compute nodes.
|
||||
|
||||
Installing the operating system
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Now that Cobbler has the correct configuration, the only thing you
|
||||
need to do is to PXE-boot your nodes. This means that they will boot over the network, with
|
||||
DHCP/TFTP provided by Cobbler, and will be provisioned accordingly,
|
||||
with the specified operating system and configuration.
|
||||
|
||||
If you installed Fuel from the ISO, start fuel-controller-01 first and let the installation finish before starting the other nodes; Fuel will cache the downloads so subsequent installs will go faster.
|
||||
|
||||
The process for each node looks like this:
|
||||
|
||||
|
||||
#. Start the VM.
|
||||
#. Press F12 immediately and select l (LAN) as a bootable media.
|
||||
#. Wait for the installation to complete.
|
||||
#. Log into the new machine using root/r00tme.
|
||||
#. **Change the root password.**
|
||||
#. Check that networking is set up correctly and the machine can reach the Internet::
|
||||
|
||||
ping fuel-pm.localdomain
|
||||
ping www.mirantis.com
|
||||
|
||||
If you're unable to ping outside addresses, add the fuel-pm server as a default gateway::
|
||||
|
||||
route add default gw 10.0.0.100
|
||||
|
||||
**It is important to note** that if you use VLANs in your network
|
||||
configuration, you always have to keep in mind the fact that PXE
|
||||
booting does not work on tagged interfaces. Therefore, all your nodes,
|
||||
including the one where the Cobbler service resides, must share one
|
||||
untagged VLAN (also called native VLAN). If necessary, you can use the
|
||||
``dhcp_interface`` parameter of the ``cobbler::server`` class to bind the DHCP
|
||||
service to the appropriate interface.
|
||||
|
||||
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
Generating the Puppet Manifest
|
||||
------------------------------
|
||||
|
||||
Before you can deploy OpenStack, you will need to configure the site.pp file. Previous versions of Fuel required you to manually configure ``site.pp``. Version 3.1 includes the ``openstack_system`` script, which uses the ``config.yaml`` file and reference architecture templates to create the appropriate Puppet manifest. To create ``site.pp``, execute this command::
|
||||
|
||||
openstack_system -c config.yaml \
|
||||
-t /etc/puppet/modules/openstack/examples/site_openstack_ha_compact.pp \
|
||||
-o /etc/puppet/manifests/site.pp \
|
||||
-a astute.yaml
|
||||
|
||||
The four parameters in the command above are:
|
||||
|
||||
* ``-c``: The absolute or relative path to the ``config.yaml`` file you customized earlier.
|
||||
* ``-t``: The template file to serve as a basis for ``site.pp``. Possible templates include ``site_openstack_ha_compact.pp``, ``site_openstack_ha_minimal.pp``, ``site_openstack_ha_full.pp``, ``site_openstack_single.pp``, and ``site_openstack_simple.pp``.
|
||||
* ``-o``: The output file. This should always be ``/etc/puppet/manifests/site.pp``.
|
||||
* ``-a``: The orchestration configuration file, to be output for use in the next step.
|
||||
|
||||
From there you're ready to install your OpenStack components. Before that, however, let's look at what is actually in the new ``site.pp`` manifest, so that you can understand how to customize it if necessary. (Similarly, if you are installing Fuel Library without the ISO, you will need to make these customizations yourself.)
|
||||
|
|
@ -1,106 +0,0 @@
|
|||
Deploying OpenStack using Puppet Manifests
|
||||
------------------------------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
You have two options for deploying OpenStack using Puppet manifests. The best
|
||||
method is to use orchestration, but you can also deploy your nodes manually.
|
||||
|
||||
.. _orchestration:
|
||||
|
||||
Deploying via orchestration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Performing a small series of manual installs many be an acceptable approach in
|
||||
some circumstances, but if you plan on deploying to a large number of servers
|
||||
then we strongly suggest that you consider orchestration. You can perform a
|
||||
deployment using orchestration with Fuel using the "astute" script. This script
|
||||
is configured using the "astute.yaml" file that was created when you ran
|
||||
"openstack_system" earlier in this process.
|
||||
|
||||
To confirm that your servers are ready for orchestration, execute the following command::
|
||||
|
||||
mco ping
|
||||
|
||||
You should see all three controllers, plus the compute node, in the response to the command::
|
||||
|
||||
fuel-compute-01 time=107.26 ms
|
||||
fuel-controller-01 time=120.14 ms
|
||||
fuel-controller-02 time=135.94 ms
|
||||
fuel-controller-03 time=139.33 ms
|
||||
|
||||
To run the orchestrator, log in to ``fuel-pm`` and execute::
|
||||
|
||||
astute -f astute.yaml
|
||||
|
||||
You will see a message on ``fuel-pm`` stating that the installation has started on fuel-controller-01. To see what's going on on the target node on Ubuntu-based OS, enter this command::
|
||||
|
||||
tail -f /var/log/syslog
|
||||
|
||||
for CentOS or RedHat use this command::
|
||||
|
||||
tail -f /var/log/messages
|
||||
|
||||
Note that Puppet will require several runs to install all the different roles. The first time it runs, the orchestrator will show an error. This error means that the installation isn't complete, but will be rectified after the various rounds of installation are completed. Also, after the first run on each server, the orchestrator doesn't output messages on fuel-pm; when it's finished running, it will return you to the command prompt. In the meantime, you can see what's going on by watching the logs on each individual machine.
|
||||
|
||||
Installing OpenStack using Puppet directly
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If, for some reason, you choose not to use orchestration -- one common example it when adding a single node to an existing (non-HA) cluster -- you have the option to install on one or more nodes using Puppet.
|
||||
|
||||
Start by logging in to the target server -- fuel-controller-01 to start, if you're starting from scratch -- and running the Puppet agent.
|
||||
|
||||
One optional step would be to use the script command to log all of your output so you can check for errors::
|
||||
|
||||
script agent-01.log
|
||||
puppet agent --test
|
||||
|
||||
You will to see a great number of messages scroll by, and the installation will take a significant amount of time. When the process has completed, press CTRL-D to stop logging and grep for errors::
|
||||
|
||||
grep err: agent-01.log
|
||||
|
||||
If you find any errors relating to other nodes you may safely ignore them for now.
|
||||
|
||||
Now you can run the same installation procedure on fuel-controller-02 and fuel-controller-03, as well as fuel-compute-01.
|
||||
|
||||
Note that the controllers must be installed sequentially due to the nature of assembling a MySQL cluster based on Galera. This means that one server must complete its installation before the next installation is started. However, compute nodes can be installed concurrently once the controllers are in place.
|
||||
|
||||
In some cases, you may find errors related to resources that are not yet available when the installation takes place. To solve that problem, simply re-run the puppet agent on the affected node after running the other controllers, and again grep for error messages. When you see no errors on any of your nodes, your OpenStack cluster is ready to go.
|
||||
|
||||
Examples of OpenStack installation sequences
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When running Puppet manually, the exact sequence depends on the configuration goals you're trying to achieve. In most cases, you'll need to run Puppet more than once; with every pass Puppet collects and adds necessary absent information to the OpenStack configuration, stores it to PuppedDB and applies necessary changes.
|
||||
|
||||
.. note::
|
||||
*Sequentially run* means you don't start the next node deployment until previous one is finished.
|
||||
|
||||
**Example 1: Full OpenStack deployment with standalone storage nodes**
|
||||
|
||||
* Create necessary volumes on storage nodes as described in :ref:`create-the-XFS-partition`.
|
||||
* Sequentially run a deployment pass on every SwiftProxy node (``fuel-swiftproxy-01 ... fuel-swiftproxy-xx``), starting with the ``primary-swift-proxy node``. Node names are set by the ``$swift_proxies`` variable in ``site.pp``. There are 2 Swift Proxies by default.
|
||||
* Sequentially run a deployment pass on every storage node (``fuel-swift-01`` ... ``fuel-swift-xx``).
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``). starting with the ``primary-controller`` node.
|
||||
* Run a deployment pass on the Neutron (formerly Quantum) node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers, these nodes may be deployed in parallel.
|
||||
* Run an additional deployment pass on Controller 1 only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
|
||||
**Example 2: Compact OpenStack deployment with storage and swift-proxy combined with nova-controller on the same nodes**
|
||||
|
||||
* Create the necessary volumes on controller nodes as described in :ref:`create-the-XFS-partition`
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``), starting with the ``primary-controller node``. Errors in Swift storage such as */Stage[main]/Swift::Storage::Container/Ring_container_device[<device address>]: Could not evaluate: Device not found check device on <device address>* are expected during the deployment passes until the very final pass.
|
||||
* Run an additional deployment pass on Controller 1 only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Run a deployment pass on the Neutron node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
||||
**Example 3:** **OpenStack HA installation without Swift**
|
||||
|
||||
* Sequentially run a deployment pass on the controller nodes (``fuel-controller-01 ... fuel-controller-xx``), starting with the primary controller. No errors should appear during this deployment pass.
|
||||
* Run an additional deployment pass on the primary controller only (``fuel-controller-01``) to finalize the Galera cluster configuration.
|
||||
* Run a deployment pass on the Neutron node (``fuel-quantum``) to install the Neutron router.
|
||||
* Run a deployment pass on every compute node (``fuel-compute-01 ... fuel-compute-xx``) - unlike the controllers these nodes may be deployed in parallel.
|
||||
|
||||
**Example 4:** **The simplest OpenStack installation: Controller + Compute on the same node**
|
||||
|
||||
* Set the ``node /fuel-controller-[\d+]/`` variable in ``site.pp`` to match the hostname of the node on which you are going to deploy OpenStack. Set the ``node /fuel-compute-[\d+]/`` variable to **mismatch** the node name. Run a deployment pass on this node. No errors should appear during this deployment pass.
|
||||
* Set the ``node /fuel-compute-[\d+]/`` variable in ``site.pp`` to match the hostname of the node on which you are going to deploy OpenStack. Set the ``node /fuel-controller-[\d+]/`` variable to **mismatch** the node name. Run a deployment pass on this node. No errors should appear during this deployment pass.
|
||||
|
|
@ -1,49 +0,0 @@
|
|||
Testing OpenStack
|
||||
-----------------
|
||||
|
||||
Now that you've installed OpenStack, its time to take your new openstack cloud for a drive around the block. Follow these steps:
|
||||
|
||||
#. On the host machine, open your browser to
|
||||
|
||||
http://192.168.0.10/ (Adjust this value to your own ``public_virtual_ip``.)
|
||||
|
||||
and login as nova/nova (unless you changed this information in ``site.pp``)
|
||||
|
||||
#. Click the Project tab in the left-hand column.
|
||||
|
||||
#. Under Manage Compute, choose Access & Security to set security settings:
|
||||
|
||||
#. Click Create Keypair and enter a name for the new keypair. The private key should download automatically; make sure to keep it safe.
|
||||
#. Click Access & Security again and click Edit Rules for the default Security Group. Add a new rule allowing TCP connections from port 22 to port 22 for all IP addresses using a CIDR of 0.0.0.0/0. (You can also customize this setting as necessary.) Click Add Rule to save the new rule.
|
||||
#. Add a second new rule allowing ICMP connections with a type and code of -1 to the default Security Group and click Add Rule to save.
|
||||
|
||||
#. Click Allocate IP To Project and add two new floating ips. Notice that they come from the pool specified in ``config.yaml`` and ``site.pp``.
|
||||
|
||||
|
||||
#. Click Images & Snapshots, then Create Image. Enter a name and specify the Image Location as https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img, with a Format of QCOW2. Check the Public checkbox.
|
||||
|
||||
#. The next step is to upload an image to use for creating VMs, but an OpenStack bug prevents you from doing this in the browser. Instead, log in to any of the controllers as root and execute the following commands::
|
||||
|
||||
cd ~
|
||||
source openrc
|
||||
glance image-create --name cirros --container-format bare --disk-format qcow2 --is-public yes --location https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-x86_64-disk.img
|
||||
|
||||
#. Go back to the browser and refresh the page. Launch a new instance of this image
|
||||
using the tiny flavor. Click the Networking tab and choose the default ``net04_ext`` network, then click the Launch button.
|
||||
|
||||
#. On the instances page:
|
||||
|
||||
#. Click the new instance and look at the settings.
|
||||
#. Click the Logs tab to look at the logs.
|
||||
#. Click the VNC tab to log in. If you see just a big black rectangle, the machine is in screensaver mode; click the grey area and press the space bar to wake it up, then login as ``cirros/cubswin:)``.
|
||||
#. At the command line, enter ``ifconfig -a | more`` and see the assigned ip address.
|
||||
#. Enter ``sudo fdisk -l`` to see that no volume has yet been assigned to this VM.
|
||||
|
||||
#. On the Instances page, click Assign Floating IP and assign an IP address to your instance. You can either choose from one of the existing created IPs by using the pulldown menu or click the plus sign (+) to choose a network and allocate a new IP address.
|
||||
#. From your host machine, ping the floating ip assigned to this VM.
|
||||
#. If that works, try to ``ssh cirros@floating-ip`` from the host machine.
|
||||
|
||||
#. Back in the browser, click Volumes and Create Volume. Create the new volume, and attach it to the instance.
|
||||
#. Go back to the VNC tab and repeat ``fdisk -l`` to see the new unpartitioned disk attached.
|
||||
|
||||
Now your new VM is ready to be used.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 6.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 7.7 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
|
|
@ -1,46 +1,87 @@
|
|||
.. index:: Sizing Hardware, Hardware Sizing
|
||||
|
||||
.. _Sizing_Hardware:
|
||||
|
||||
Sizing Hardware
|
||||
---------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
One of the first questions people ask when planning an OpenStack deployment is "what kind of hardware do I need?" There is no such thing as a one-size-fits-all answer, but there are straightforward rules to selecting appropriate hardware that will suit your needs. The Golden Rule, however, is to always accomodate for growth. With the potential for growth accounted for, you can move on to the actual hardware needs.
|
||||
One of the first questions people ask when planning an OpenStack deployment is
|
||||
"what kind of hardware do I need?" There is no such thing as a one-size-fits-all
|
||||
answer, but there are straightforward rules to selecting appropriate hardware
|
||||
that will suit your needs. The Golden Rule, however, is to always accommodate
|
||||
for growth. With the potential for growth accounted for, you can move on to the
|
||||
actual hardware needs.
|
||||
|
||||
Many factors contribute to selecting hardware for an OpenStack cluster -- `contact Mirantis <http://www.mirantis.com/contact/>`_ for information on your specific requirements -- but in general, you will want to consider the following factors:
|
||||
Many factors contribute to selecting hardware for an OpenStack cluster --
|
||||
`contact Mirantis <http://www.mirantis.com/contact/>`_ for information on your
|
||||
specific requirements -- but in general, you will want to consider the following
|
||||
factors:
|
||||
|
||||
* Processing
|
||||
* Memory
|
||||
* Storage
|
||||
* Networking
|
||||
|
||||
Your needs in each of these areas are going to determine your overall hardware requirements.
|
||||
Your needs in each of these areas are going to determine your overall hardware
|
||||
requirements.
|
||||
|
||||
Processing
|
||||
^^^^^^^^^^
|
||||
|
||||
In order to calculate how much processing power you will need to aquire you will need to determine the number of VMs your cloud will support. You must also consider the average and maximum processor resources you will allocate to each VM. In the vast majority of deployments, the allocated resources will be the same for all of your VMs. However, if you are planning to create groups of VMs that have different requirements, you will need to calculate for all of them in aggregate. Consider this example:
|
||||
In order to calculate how much processing power you need to acquire you will
|
||||
need to determine the number of VMs your cloud will support. You must also
|
||||
consider the average and maximum processor resources you will allocate to each
|
||||
VM. In the vast majority of deployments, the allocated resources will be the
|
||||
same for all of your VMs. However, if you are planning to create groups of VMs
|
||||
that have different requirements, you will need to calculate for all of them in
|
||||
aggregate. Consider this example:
|
||||
|
||||
* 100 VMs
|
||||
* 2 EC2 compute units (2 GHz) average
|
||||
* 16 EC2 compute units (16 GHz) max
|
||||
|
||||
To make it possible to provide the maximum CPU in this example you will need at least 5 cores (16 GHz/(2.4 GHz per core * 1.3 to adjust for hyperthreading)) per machine, and at least 84 cores ((100 VMs * 2 GHz per VM)/2.4 GHz per core) in total. If you were to select the Intel E5 2650-70 8 core CPU, that means you need 11 sockets (84 cores / 8 cores per socket). This breaks down to six dual core servers (12 sockets / 2 sockets per server), for a "packing density" of 17 VMs per server (102 VMs / 6 servers).
|
||||
To make it possible to provide the maximum CPU in this example you will need at
|
||||
least 5 CPU cores (16 GHz/(2.4 GHz per core * 1.3 to adjust for hyper-threading))
|
||||
per machine, and at least 84 CPU cores ((100 VMs * 2 GHz per VM)/2.4 GHz per
|
||||
core) in total. If you were to select the Intel E5 2650-70 8 core CPU, that
|
||||
means you need 11 sockets (84 cores / 8 cores per socket). This breaks down to
|
||||
six dual core servers (12 sockets / 2 sockets per server), for a "packing
|
||||
density" of 17 VMs per server (102 VMs / 6 servers).
|
||||
|
||||
This process also accomodates growth since you now know what a single server using this CPU configuration can support. You can add new servers accounting for 17 VMs each as needed without having to re-calculate.
|
||||
This process also accommodates growth since you now know what a single server
|
||||
using this CPU configuration can support. You can add new servers accounting
|
||||
for 17 VMs each as needed without having to re-calculate.
|
||||
|
||||
You will also need to take into account the following:
|
||||
|
||||
* This model assumes you are not oversubscribing your CPU.
|
||||
* If you are considering Hyperthreading, count each core as 1.3, not 2.
|
||||
* If you are considering Hyper-threading, count each core as 1.3, not 2.
|
||||
* Choose a good value CPU that supports the technologies you require.
|
||||
|
||||
Memory
|
||||
^^^^^^
|
||||
|
||||
Continuing to use the example from the previous section, we need to determine how much RAM will be required to support 17 VMs per server. Let's assume that you need an average of 4GBs of RAM per VM with dynamic allocation for up to 12GBs for each VM. Calculating that all VMs will be using 12GBs of RAM requires that each server have 204GBs of available RAM.
|
||||
Continuing to use the example from the previous section, we need to determine
|
||||
how much RAM will be required to support 17 VMs per server. Let's assume that
|
||||
you need an average of 4GBs of RAM per VM with dynamic allocation for up to
|
||||
12GBs for each VM. Calculating that all VMs will be using 12GBs of RAM requires
|
||||
that each server have 204GBs of available RAM.
|
||||
|
||||
You must also consider that the node itself needs sufficient RAM to accomodate core OS operations as well as RAM for each VM container (not the RAM allocated to each VM, but the memory the core OS uses to run the VM). The node's OS must run it's own operations, schedule proccesses, allocate dynamic resources, and handle network operations, so giving the node itself at least 16GBs or more RAM is not unreasonable.
|
||||
You must also consider that the node itself needs sufficient RAM to accommodate
|
||||
core OS operations as well as RAM for each VM container (not the RAM allocated
|
||||
to each VM, but the memory the core OS uses to run the VM). The node's OS must
|
||||
run it's own operations, schedule processes, allocate dynamic resources, and
|
||||
handle network operations, so giving the node itself at least 16GBs or more RAM
|
||||
is not unreasonable.
|
||||
|
||||
Considering that the RAM we would consider for servers comes in 4GB, 8GB, 16GB, and 32GB sticks, we would need a total of 265GBs of RAM installed per server. For an average 2-CPU server board you get 16-24 RAM slots. To have 256GBs installed you would need sixteen 16GB sticks of RAM to satisfy your RAM needs for up to 17 VMs requiring dynamic allocation up to 12GBs and to support all core OS requirements.
|
||||
Considering that the RAM we would consider for servers comes in 4GB, 8GB, 16GB
|
||||
and 32GB sticks, we would need a total of 265GBs of RAM installed per server.
|
||||
For an average 2-CPU socket server board you get 16-24 RAM slots. To have
|
||||
256GBs installed you would need sixteen 16GB sticks of RAM to satisfy your RAM
|
||||
needs for up to 17 VMs requiring dynamic allocation up to 12GBs and to support
|
||||
all core OS requirements.
|
||||
|
||||
You can adjust this calculation based on your needs.
|
||||
|
||||
|
|
@ -53,44 +94,78 @@ When it comes to disk space there are several types that you need to consider:
|
|||
* Persistent (the remote volumes that can be attached to a VM)
|
||||
* Object Storage (such as images or other objects)
|
||||
|
||||
As far as local drive space that must reside on the compute nodes, in our example of 100 VMs we make the following assumptions:
|
||||
As far as local drive space that must reside on the compute nodes, in our
|
||||
example of 100 VMs we make the following assumptions:
|
||||
|
||||
* 150 GB local storage per VM
|
||||
* 5 TB total of local storage (100 VMs * 50 GB per VM)
|
||||
* 500 GB of persistent volume storage per VM
|
||||
* 50 TB total persistent storage
|
||||
|
||||
Returning to our already established example, we need to figure out how much storage to install per server. This storage will service the 17 VMs per server. If we are assuming 50GBs of storage for each VMs drive container, then we would need to install 2.5TBs of storage on the server. Since most servers have anywhere from 4 to 32 2.5" drive slots or 2 to 12 3.5" drive slots, depending on server form factor (i.e., 2U vs. 4U), you will need to consider how the storage will be impacted by the intended use.
|
||||
Returning to our already established example, we need to figure out how much
|
||||
storage to install per server. This storage will service the 17 VMs per server.
|
||||
If we are assuming 50GBs of storage for each VMs drive container, then we would
|
||||
need to install 2.5TBs of storage on the server. Since most servers have
|
||||
anywhere from 4 to 32 2.5" drive slots or 2 to 12 3.5" drive slots, depending on
|
||||
server form factor (i.e., 2U vs. 4U), you will need to consider how the storage
|
||||
will be impacted by the intended use.
|
||||
|
||||
If storage impact is not expected to be significant, then you may consider using unified storage. For this example a single 3TB drive would provide more than enough storage for 17 150GB VMs. If speed is really not an issue, you might even consider installing two or three 3TB drives and configure a RAID-1 or RAID-5 for redundancy. If speed is critical, however, you will likely want to have a single hardware drive for each VM. In this case you would likely look at a 3U form factor with 24-slots.
|
||||
If storage impact is not expected to be significant, then you may consider using
|
||||
unified storage. For this example a single 3TB drive would provide more than
|
||||
enough storage for 17 150GB VMs. If speed is really not an issue, you might even
|
||||
consider installing two or three 3TB drives and configure a RAID-1 or RAID-5
|
||||
for redundancy. If speed is critical, however, you will likely want to have a
|
||||
single hardware drive for each VM. In this case you would likely look at a 3U
|
||||
form factor with 24-slots.
|
||||
|
||||
Don't forget that you will also need drive space for the node itself, and don't forget to order the correct backplane that supports the drive configuration that meets your needs. Using our example specifications and assuming that speed it critical, a single server would need 18 drives, most likely 2.5" 15,000RPM 146GB SAS drives.
|
||||
Don't forget that you will also need drive space for the node itself, and don't
|
||||
forget to order the correct backplane that supports the drive configuration
|
||||
that meets your needs. Using our example specifications and assuming that speed
|
||||
it critical, a single server would need 18 drives, most likely 2.5" 15,000RPM
|
||||
146GB SAS drives.
|
||||
|
||||
Throughput
|
||||
~~~~~~~~~~
|
||||
|
||||
As far as throughput, that's going to depend on what kind of storage you choose. In general, you calculate IOPS based on the packing density (drive IOPS * drives in the server / VMs per server), but the actual drive IOPS will depend on the drive technology you choose. For example:
|
||||
As far as throughput, that's going to depend on what kind of storage you choose.
|
||||
In general, you calculate IOPS based on the packing density (drive IOPS * drives
|
||||
in the server / VMs per server), but the actual drive IOPS will depend on the
|
||||
drive technology you choose. For example:
|
||||
|
||||
* 3.5" slow and cheap (100 IOPS per drive, with 2 mirrored drives)
|
||||
|
||||
* 100 IOPS * 2 drives / 17 VMs per server = 12 Read IOPS, 6 Write IOPS
|
||||
* 100 IOPS * 2 drives / 17 VMs per server = 12 Read IOPS, 6 Write IOPS
|
||||
|
||||
* 2.5" 15K (200 IOPS, 4 600 GB drive, RAID 10)
|
||||
|
||||
* 200 IOPS * 4 drives / 17 VMs per server = 48 Read IOPS, 24 Write IOPS
|
||||
* 200 IOPS * 4 drives / 17 VMs per server = 48 Read IOPS, 24 Write IOPS
|
||||
|
||||
* SSD (40K IOPS, 8 300 GB drive, RAID 10)
|
||||
|
||||
* 40K * 8 drives / 17 VMs per server = 19K Read IOPS, 9.5K Write IOPS
|
||||
* 40K * 8 drives / 17 VMs per server = 19K Read IOPS, 9.5K Write IOPS
|
||||
|
||||
Clearly, SSD gives you the best performance, but the difference in cost between SSDs and the less costly platter-based solutions is going to be signficant, to say the least. The acceptable cost burden is determined by the balance between your budget and your performance and redundancy needs. It is also important to note that the rules for redundancy in a cloud environment are different than a traditional server installation in that entire servers provide redundancy as opposed to making a single server instance redundant.
|
||||
Clearly, SSD gives you the best performance, but the difference in cost between
|
||||
SSDs and the less costly platter-based solutions is going to be significant, to
|
||||
say the least. The acceptable cost burden is determined by the balance between
|
||||
your budget and your performance and redundancy needs. It is also important to
|
||||
note that the rules for redundancy in a cloud environment are different than a
|
||||
traditional server installation in that entire servers provide redundancy as
|
||||
opposed to making a single server instance redundant.
|
||||
|
||||
In other words, the weight for redundant components shifts from individual OS installation to server redundancy. It is far more critical to have redundant power supplies and hot-swappable CPUs and RAM than to have redundant compute node storage. If, for example, you have 18 drives installed on a server and have 17 drives directly allocated to each VM installed and one fails, you simply replace the drive and push a new node copy. The remaining VMs carry whatever additional load is present due to the temporary loss of one node.
|
||||
In other words, the weight for redundant components shifts from individual OS
|
||||
installation to server redundancy. It is far more critical to have redundant
|
||||
power supplies and hot-swappable CPUs and RAM than to have redundant compute
|
||||
node storage. If, for example, you have 18 drives installed on a server and have
|
||||
17 drives directly allocated to each VM installed and one fails, you simply
|
||||
replace the drive and push a new node copy. The remaining VMs carry whatever
|
||||
additional load is present due to the temporary loss of one node.
|
||||
|
||||
Remote storage
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
IOPS will also be a factor in determining how you plan to handle persistent storage. For example, consider these options for laying out your 50 TB of remote volume space:
|
||||
IOPS will also be a factor in determining how you plan to handle persistent
|
||||
storage. For example, consider these options for laying out your 50 TB of remote
|
||||
volume space:
|
||||
|
||||
* 12 drive storage frame using 3 TB 3.5" drives mirrored
|
||||
|
||||
|
|
@ -106,19 +181,44 @@ IOPS will also be a factor in determining how you plan to handle persistent stor
|
|||
* 24 slots x 100 IOPS per drive = 2400 Read IOPS, 1200 Write IOPS per frame
|
||||
* 5 frames x 2400 IOPS per frame / 100 VMs = 120 Read IOPS, 60 Write IOPS per frame
|
||||
|
||||
You can accomplish the same thing with a single 36 drive frame using 3 TB drives, but this becomes a single point of failure in your cluster.
|
||||
You can accomplish the same thing with a single 36 drive frame using 3 TB
|
||||
drives, but this becomes a single point of failure in your cluster.
|
||||
|
||||
Object storage
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
When it comes to object storage, you will find that you need more space than you think. For example, this example specifies 50 TB of object storage. Easy right? Not really. Object storage uses a default of 3 times the required space for replication, which means you will need 150 TB. However, to accommodate two hands-off zones, you will need 5 times the required space, which actually means 250 TB. The calculations don't end there. You don't ever want to run out of space, so "full" should really be more like 75% of capacity, which means you will need a total of 333 TB, or a multiplication factor of 6.66.
|
||||
When it comes to object storage, you will find that you need more space than
|
||||
you think. For example, this example specifies 50 TB of object storage.
|
||||
|
||||
Of course, that might be a bit much to start with; you might want to start with a happy medium of a multiplier of 4, then acquire more hardware as your drives begin to fill up. That calculates to 200 TB in our example. So how do you put that together? If you were to use 3 TB 3.5" drives, you could use a 12 drive storage frame, with 6 servers hosting 36 TB each (for a total of 216 TB). You could also use a 36 drive storage frame, with just 2 servers hosting 108 TB each, but its not recommended due to the high cost of failure to replication and capacity issues.
|
||||
Easy right? Not really.
|
||||
|
||||
Object storage uses a default of 3 times the required space for replication,
|
||||
which means you will need 150 TB. However, to accommodate two hands-off zones,
|
||||
you will need 5 times the required space, which actually means 250 TB.
|
||||
The calculations don't end there. You don't ever want to run out of space, so
|
||||
"full" should really be more like 75% of capacity, which means you will need a
|
||||
total of 333 TB, or a multiplication factor of 6.66.
|
||||
|
||||
Of course, that might be a bit much to start with; you might want to start
|
||||
with a happy medium of a multiplier of 4, then acquire more hardware as your
|
||||
drives begin to fill up. That calculates to 200 TB in our example. So how do
|
||||
you put that together? If you were to use 3 TB 3.5" drives, you could use a 12
|
||||
drive storage frame, with 6 servers hosting 36 TB each (for a total of 216 TB).
|
||||
You could also use a 36 drive storage frame, with just 2 servers hosting 108 TB
|
||||
each, but its not recommended due to the high cost of failure to replication
|
||||
and capacity issues.
|
||||
|
||||
Networking
|
||||
^^^^^^^^^^
|
||||
|
||||
Perhaps the most complex part of designing an OpenStack cluster is the networking. An OpenStack cluster can involve multiple networks even beyond the Public, Private, and Internal networks. Your cluster may involve tenant networks, storage networks, multiple tenant private networks, and so on. Many of these will be VLANs, and all of them will need to be planned out in advance to avoid configuration issues.
|
||||
Perhaps the most complex part of designing an OpenStack cluster is the
|
||||
networking.
|
||||
|
||||
An OpenStack cluster can involve multiple networks even beyond the Public,
|
||||
Private, and Internal networks. Your cluster may involve tenant networks,
|
||||
storage networks, multiple tenant private networks, and so on. Many of these
|
||||
will be VLANs, and all of them will need to be planned out in advance to avoid
|
||||
configuration issues.
|
||||
|
||||
In terms of the example network, consider these assumptions:
|
||||
|
||||
|
|
@ -126,33 +226,55 @@ In terms of the example network, consider these assumptions:
|
|||
* HA architecture
|
||||
* Network Storage is not latency sensitive
|
||||
|
||||
In order to achieve this, you can use two 1Gb links per server (2 x 1000 Mbits/second / 17 VMs = 118 Mbits/second). Using two links also helps with HA. You can also increase throughput and decrease latency by using 2 10 Gb links, bringing the bandwidth per VM to 1 Gb/second, but if you're going to do that, you've got one more factor to consider.
|
||||
In order to achieve this, you can use two 1Gb links per server (2 x 1000
|
||||
Mbits/second / 17 VMs = 118 Mbits/second).
|
||||
|
||||
Using two links also helps with HA. You can also increase throughput and
|
||||
decrease latency by using two 10 Gb links, bringing the bandwidth per VM to
|
||||
1 Gb/second, but if you're going to do that, you've got one more factor to
|
||||
consider.
|
||||
|
||||
Scalability and oversubscription
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is one of the ironies of networking that 1Gb Ethernet generally scales better than 10Gb Ethernet -- at least until 100Gb switches are more commonly available. It's possible to aggregate the 1Gb links in a 48 port switch, so that you have 48 1Gb links down, but 4 10GB links up. Do the same thing with a 10Gb switch, however, and you have 48 10Gb links down and 4 100Gb links up, resulting in oversubscription.
|
||||
It is one of the ironies of networking that 1Gb Ethernet generally scales
|
||||
better than 10Gb Ethernet -- at least until 100Gb switches are more commonly
|
||||
available. It's possible to aggregate the 1Gb links in a 48 port switch, so
|
||||
that you have 48 1Gb links down, but 4 10GB links up. Do the same thing with a
|
||||
10Gb switch, however, and you have 48 10Gb links down and 4 100Gb links up,
|
||||
resulting in oversubscription.
|
||||
|
||||
Like many other issues in OpenStack, you can avoid this problem to a great extent with careful planning. Problems only arise when you are moving between racks, so plan to create "pods", each of which includes both storage and compute nodes. Generally, a pod is the size of a non-oversubscribed L2 domain.
|
||||
Like many other issues in OpenStack, you can avoid this problem to a great
|
||||
extent with careful planning. Problems only arise when you are moving between
|
||||
racks, so plan to create "pods", each of which includes both storage and
|
||||
compute nodes. Generally, a pod is the size of a non-oversubscribed L2 domain.
|
||||
|
||||
Hardware for this example
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In this example, you are looking at:
|
||||
|
||||
* 2 data switches (for HA), each with a minimum of 12 ports for data (2 x 1Gb links per server x 6 servers)
|
||||
* 2 data switches (for HA), each with a minimum of 12 ports for data
|
||||
(2 x 1Gb links per server x 6 servers)
|
||||
* 1 1Gb switch for IPMI (1 port per server x 6 servers)
|
||||
* Optional Cluster Management switch, plus a second for HA
|
||||
|
||||
Because your network will in all likelihood grow, it's best to choose 48 port switches. Also, as your network grows, you will need to consider uplinks and aggregation switches.
|
||||
Because your network will in all likelihood grow, it's best to choose 48 port
|
||||
switches. Also, as your network grows, you will need to consider uplinks and
|
||||
aggregation switches.
|
||||
|
||||
Summary
|
||||
^^^^^^^
|
||||
|
||||
In general, your best bet is to choose a 2 socket server with a balance in I/O, CPU, Memory, and Disk that meets your project requirements. Look for a 1U R-class or 2U high density C-class server. Some good options from Dell for compute nodes include:
|
||||
In general, your best bet is to choose a 2 socket server with a balance in I/O,
|
||||
CPU, Memory, and Disk that meets your project requirements.
|
||||
Look for a 1U R-class or 2U high density C-class servers. Some good options
|
||||
from Dell for compute nodes include:
|
||||
|
||||
* Dell PowerEdge R620
|
||||
* Dell PowerEdge C6220 Rack Server
|
||||
* Dell PowerEdge R720XD (for high disk or IOPS requirements)
|
||||
|
||||
You may also want to consider systems from HP (http://www.hp.com/servers) or from a smaller systems builder like Aberdeen, a manufacturer that specializes in powerful, low-cost systems and storage servers (http://www.aberdeeninc.com).
|
||||
You may also want to consider systems from HP (http://www.hp.com/servers) or
|
||||
from a smaller systems builder like Aberdeen, a manufacturer that specializes
|
||||
in powerful, low-cost systems and storage servers (http://www.aberdeeninc.com).
|
||||
|
|
@ -1,22 +1,41 @@
|
|||
.. index:: Redeploying An Environment
|
||||
|
||||
.. _Redeploying_An_Environment:
|
||||
|
||||
Redeploying An Environment
|
||||
--------------------------
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Because Puppet is additive only, there is no ability to revert changes as you would in a typical application deployment. If a change needs to be backed out, you must explicitly add a configuration to reverse it, check the configuration in, and promote it to production using the pipeline. This means that if a breaking change does get deployed into production, typically a manual fix is applied, with the proper fix subsequently checked into version control.
|
||||
Because Puppet is additive only, there is no ability to revert changes as you
|
||||
would in a typical application deployment. If a change needs to be backed out,
|
||||
you must explicitly add a configuration to reverse it, check the configuration
|
||||
in, and promote it to production using the pipeline. This means that if a
|
||||
breaking change does get deployed into production, typically a manual fix is
|
||||
applied, with the proper fix subsequently checked into version control.
|
||||
|
||||
Fuel offers the ability to isolate code changes while developing a deployment and minimizes the headaches associated with maintaining multiple configurations through a single Puppet Master by creating what are called environments.
|
||||
Fuel offers the ability to isolate code changes while developing a deployment
|
||||
and minimizes the headaches associated with maintaining multiple configurations
|
||||
through a single Puppet Master by creating what are called environments.
|
||||
|
||||
Environments
|
||||
^^^^^^^^^^^^
|
||||
|
||||
Puppet supports assigning nodes 'environments'. These environments can be mapped directly to your development, QA and production life cycles, so it’s a way to distribute code to nodes that are assigned to those environments.
|
||||
Puppet supports assigning nodes 'environments'. These environments can be
|
||||
mapped directly to your development, QA and production life cycles, so it’s a
|
||||
way to distribute code to nodes that are assigned to those environments.
|
||||
|
||||
* On the Master/Server Node
|
||||
* On the Master Node
|
||||
|
||||
The Puppet Master tries to find modules using its ``modulepath`` setting, which by default is ``/etc/puppet/modules``. It is common practice to set this value once in your ``/etc/puppet/puppet.conf``. Environments expand on this idea and give you the ability to use different settings for different configurations.
|
||||
The Puppet Master tries to find modules using its ``modulepath`` setting,
|
||||
which by default is ``/etc/puppet/modules``. It is common practice to set
|
||||
this value once in your ``/etc/puppet/puppet.conf``. Environments expand on
|
||||
this idea and give you the ability to use different settings for different
|
||||
configurations.
|
||||
|
||||
For example, you can specify several search paths. The following example dynamically sets the ``modulepath`` so Puppet will check a per-environment folder for a module before serving it from the main set::
|
||||
For example, you can specify several search paths. The following example
|
||||
dynamically sets the ``modulepath`` so Puppet will check a per-environment
|
||||
folder for a module before serving it from the main set::
|
||||
|
||||
[master]
|
||||
modulepath = $confdir/$environment/modules:$confdir/modules
|
||||
|
|
@ -27,38 +46,48 @@ Puppet supports assigning nodes 'environments'. These environments can be mapped
|
|||
[development]
|
||||
manifest = $confdir/$environment/manifests/site.pp
|
||||
|
||||
* On the Agent Node
|
||||
* On the Slave Node
|
||||
|
||||
Once the agent node makes a request, the Puppet Master gets informed of its environment. If you don’t specify an environment, the agent uses the default ``production`` environment.
|
||||
Once the slave node makes a request, the Puppet Master gets informed of its
|
||||
environment. If you don’t specify an environment, the agent uses the default
|
||||
``production`` environment.
|
||||
|
||||
To set an environment agent-side, just specify the environment setting in the ``[agent]`` block of ``puppet.conf``::
|
||||
To set aslave-side environment, just specify the environment setting in the
|
||||
``[agent]`` block of ``puppet.conf``::
|
||||
|
||||
[agent]
|
||||
environment = development
|
||||
|
||||
|
||||
Deployment pipeline
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
* Deploy
|
||||
|
||||
In order to deploy multiple environments that don't interfere with each other, you should specify the ``$deployment_id`` option in ``/etc/puppet/manifests/site.pp``. It should be an even integer value in the range of 2-254.
|
||||
In order to deploy multiple environments that don't interfere with each other,
|
||||
you should specify the ``$deployment_id`` option in
|
||||
``/etc/puppet/manifests/site.pp``. It should be an even integer value in the
|
||||
range of 2-254.
|
||||
|
||||
This value is used in dynamic environment-based tag generation. Fuel applies that tag globally to all resources on each node. It is also used for the keepalived daemon, which evaluates a unique ``virtual_router_id``.
|
||||
This value is used in dynamic environment-based tag generation. Fuel applies
|
||||
that tag globally to all resources and some services on each node.
|
||||
|
||||
* Clean/Revert
|
||||
|
||||
At this stage you just need to make sure the environment has the original/virgin state.
|
||||
At this stage you just need to make sure the environment has the
|
||||
original/virgin state.
|
||||
|
||||
* Puppet node deactivate
|
||||
|
||||
This will ensure that any resources exported by that node will stop appearing in the catalogs served to the agent nodes::
|
||||
This will ensure that any resources exported by that node will stop appearing
|
||||
in the catalogs served to the slave nodes::
|
||||
|
||||
puppet node deactivate <node>
|
||||
|
||||
where ``<node>`` is the fully qualified domain name as seen in ``puppet cert list --all``.
|
||||
where ``<node>`` is the fully qualified domain name as seen in
|
||||
``puppet cert list --all``.
|
||||
|
||||
You can deactivate nodes manually one by one, or execute the following command to automatically deactivate all nodes::
|
||||
You can deactivate nodes manually one by one, or execute the following
|
||||
command to automatically deactivate all nodes::
|
||||
|
||||
cert list --all | awk '! /DNS:puppet/ { gsub(/"/, "", $2); print $2}' | xargs puppet node deactivate
|
||||
|
||||
|
|
@ -66,8 +95,8 @@ Deployment pipeline
|
|||
|
||||
Start the puppet agent again to apply a desired node configuration.
|
||||
|
||||
Links
|
||||
^^^^^
|
||||
.. seealso::
|
||||
|
||||
* http://puppetlabs.com/blog/a-deployment-pipeline-for-infrastructure/
|
||||
* http://docs.puppetlabs.com/guides/environment.html
|
||||
http://puppetlabs.com/blog/a-deployment-pipeline-for-infrastructure/
|
||||
|
||||
http://docs.puppetlabs.com/guides/environment.html
|
||||
|
|
|
|||
|
|
@ -1,35 +1,81 @@
|
|||
.. index:: Large Scale Deployments
|
||||
|
||||
.. _Large_Scale_Deployments:
|
||||
|
||||
Large Scale Deployments
|
||||
-----------------------
|
||||
|
||||
When deploying large clusters (of 100 nodes or more) there are two basic
|
||||
bottlenecks:
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
When deploying large clusters -- those of 100 nodes or more -- there are two basic bottlenecks:
|
||||
Careful planning is key to eliminating these potential problem areas, but
|
||||
there's another way.
|
||||
|
||||
* Certificate signing requests and Puppet Master/Cobbler capacity
|
||||
* Downloading of operating systems and other software
|
||||
|
||||
Careful planning is key to eliminating these potential problem areas, but there's another way. If you are deploying Fuel 3.1 from the ISO, Fuel takes care of these problems through caching and orchestration. We feel, however, that it's always good to have a sense of how to solve these problems should they appear.
|
||||
Fuel takes care of these problems through caching and orchestration. We feel,
|
||||
however, that it's always good to have a sense of how to solve these problems
|
||||
should they appear.
|
||||
|
||||
Certificate signing requests and Puppet Master/Cobbler capacity
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When deploying a large cluster, you may find that Puppet Master begins to have difficulty when you start exceeding 20 or more simultaneous requests. Part of this problem is because the initial process of requesting and signing certificates involves \*.tmp files that can create conflicts. To solve this problem, you have two options: reduce the number of simultaneous requests, or increase the number of Puppet Master/Cobbler servers.
|
||||
When deploying a large cluster, you may find that Puppet Master begins to have
|
||||
difficulty when you start exceeding 20 or more simultaneous requests. Part of
|
||||
this problem is because the initial process of requesting and signing
|
||||
certificates involves \*.tmp files that can create conflicts. To solve this
|
||||
problem, you have two options:
|
||||
|
||||
The number of simultaneous certificate requests that are active can be controlled by staggering the Puppet agent run schedule. This can be accomplished through orchestration. You don't need extreme staggering -- 1 to 5 seconds will do -- but if this method isn't practical, you can increase the number of Puppet Master/Cobbler servers.
|
||||
* reduce the number of simultaneous requests,
|
||||
* or increase the number of Puppet Master/Cobbler servers.
|
||||
|
||||
If you're simply overwhelming the Puppet Master process and not running into file conflicts, one way to get around this problem is to use Puppet Master with Thin as the backend component and nginx as a front end component. This configuration dynamically scales the number of Puppet Master processes to better accommodate changing load.
|
||||
The number of simultaneous certificate requests that are active can be
|
||||
controlled by staggering the Puppet agent run schedule. This can be
|
||||
accomplished through orchestration. You don't need extreme staggering (1 to 5
|
||||
seconds will do) but if this method isn't practical, you can increase the number
|
||||
of Puppet Master/Cobbler servers.
|
||||
|
||||
You can find sample configuration files for nginx and puppetmasterd at [CONTENT NEEDED HERE].
|
||||
If you're simply overwhelming the Puppet Master process and not running into
|
||||
file conflicts, one way to get around this problem is to use Puppet Master with
|
||||
Thin as the backend component and nginx as a frontend component. This
|
||||
configuration dynamically scales the number of Puppet Master processes to better
|
||||
accommodate changing load.
|
||||
|
||||
You can also increase the number of servers by creating a cluster that utilizes a round robin DNS configuration through a service like HAProxy. You will need to ensure that these nodes are kept in sync. For Cobbler, that means a combination of the --replicate switch, XMLRPC for metadata, rsync for profiles and distributions. Similarly, Puppet Master and PuppetDB can be kept in sync with a combination of rsync (for modules, manifests, and SSL data) and database replication.
|
||||
.. You can find sample configuration files for nginx and puppetmasterd at [CONTENT NEEDED HERE].
|
||||
|
||||
.. image:: /pages/production-considerations/cobbler-puppet-ha.png
|
||||
You can also increase the number of servers by creating a cluster that utilizes
|
||||
a round robin DNS configuration through a service like HAProxy. You will need
|
||||
to ensure that these nodes are kept in sync. For Cobbler, that means a
|
||||
combination of the ``--replicate`` switch, XMLRPC for metadata, rsync for
|
||||
profiles and distributions. Similarly, Puppet Master can be kept in sync with a
|
||||
combination of rsync (for modules, manifests, and SSL data) and database
|
||||
replication.
|
||||
|
||||
.. image:: /_images/cobbler-puppet-ha.png
|
||||
:width: 400px
|
||||
:height: 190px
|
||||
|
||||
Downloading of operating systems and other software
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Large deployments can also suffer from a bottleneck in terms of the additional traffic created by downloading software from external sources. One way to avoid this problem is by increasing LAN bandwidth through bonding multiple gigabit interfaces. You might also want to consider 10G Ethernet trunking between infrastructure switches using CAT-6a or fiber to improve backend speeds to reduce latency and provide more overall pipe. (See "Sizing Hardware" for more information on choosing networking equipment.)
|
||||
Large deployments can also suffer from a bottleneck in terms of the additional
|
||||
traffic created by downloading software from external sources. One way to avoid
|
||||
this problem is by increasing LAN bandwidth through bonding multiple gigabit
|
||||
interfaces. You might also want to consider 10G Ethernet trunking between
|
||||
infrastructure switches using CAT-6a or fiber cables to improve backend speeds
|
||||
to reduce latency and provide more overall pipe.
|
||||
|
||||
Another option is to prevent the need to download so much data in the first place using either apt-cacher to cache frequently downloaded packages or to set up a private repository. The downside of using your own repository, however, is that you have to spend more time manually updating it. Apt-cacher automates this process. To use apt-cacher, the kickstart that Cobbler sends to each node should specify Cobbler's IP address and the apt-cacher port as the proxy server. This will prevent all of the nodes from having to download the software individually.
|
||||
.. seealso:: :ref:`Sizing_Hardware` for more information on choosing networking equipment.
|
||||
|
||||
`Contact Mirantis <http://www.mirantis.com/contact/>`_ for information on creating a private repository.
|
||||
..
|
||||
Another option is to prevent the need to download so much data in the first place
|
||||
using either apt-cacher to cache frequently downloaded packages or to set up a
|
||||
private repository. The downside of using your own repository, however, is that
|
||||
you have to spend more time manually updating it. Apt-cacher automates this
|
||||
process. To use apt-cacher, the kickstart that Cobbler sends to each node
|
||||
should specify Cobbler's IP address and the apt-cacher port as the proxy server.
|
||||
This will prevent all of the nodes from having to download the software
|
||||
individually.
|
||||
|
||||
`Contact Mirantis <http://www.mirantis.com/contact/>`_ for information on
|
||||
creating a private repository.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,341 @@
|
|||
Post-deployment check
|
||||
=====================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
On occasion, even a successful deployment may result in some OpenStack
|
||||
components not working correctly or behaving as expected. If this happens,
|
||||
Fuel 3.1 offers the ability to perform post-deployment checks to verify
|
||||
operations. Part of Fuel's goal is to provide easily accessible status
|
||||
information about the most commonly used components and the most recently
|
||||
performed actions. To perform these checks you will use Sanity and Smoke
|
||||
checks, as described below:
|
||||
|
||||
* **Sanity Checks** reveal whether the overall system is functional. If
|
||||
it fails, you will most likely need to restart some services to operate
|
||||
OpenStack.
|
||||
* **Smoke Checks** dive in a little deeper and reveal networking,
|
||||
system-requirements, functionality issues.
|
||||
|
||||
Sanity Checks will likely be the point on which the success of your
|
||||
deployment pivots, but it is critical to pay close attention to all
|
||||
information collected from theses tests. Another way to look at these tests
|
||||
is by their names. Sanity Checks are intended to assist in maintaining your
|
||||
sanity. Smoke Checks tell you where the fires are so you can put them out
|
||||
strategically instead of firehosing the entire installation.
|
||||
|
||||
Benefits
|
||||
--------
|
||||
|
||||
* Using post-deployment checks helps you identify potential issues which
|
||||
may impact the health of a deployed system.
|
||||
* All post-deployment checks provide detailed descriptions about failed
|
||||
operations and tell you which component or components are not working
|
||||
properly.
|
||||
* Previously, performing these checks manually would have consumed a
|
||||
great deal of time. Now, with these checks the process will take only a
|
||||
few minutes.
|
||||
* Aside from verifying that everything is working correctly, the process
|
||||
will also determine how quickly your system works.
|
||||
* Post-deployment checks continue to be useful, for example after
|
||||
sizable changes are made in the system you can use the checks to
|
||||
determine if any new failure points have been introduced.
|
||||
|
||||
Running post-deployment checks
|
||||
------------------------------
|
||||
|
||||
.. image:: /_images/001-health-check-tab.png
|
||||
:align: center
|
||||
|
||||
As you can see in the image above, the Fuel UI now contains a “Healthcheck”
|
||||
tab, indicated by the Heart icon.
|
||||
|
||||
All of the post-deployment checks are displayed on this tab. If your
|
||||
deployment was successful, you will see a list of tests this show a green
|
||||
Thumbs Up in the last column. The Thumb indicates the status of the
|
||||
component. If you see a detailed message and a Thumbs Down, that
|
||||
component has failed in some manner, and the details will indicate where the
|
||||
failure was detected. All tests can be run on different environments, which
|
||||
you select on main page of Fuel UI. You can run checks in parallel on
|
||||
different environments.
|
||||
|
||||
Each test contains information on its estimated and actual duration. We have
|
||||
included information about test processing time from our own tests and
|
||||
indicate this in each test. Note that we show average times from the slowest
|
||||
to the fastest systems we have tested, so your results will vary.
|
||||
|
||||
Once a test is complete the results will appear in the Status column. If
|
||||
there was an error during the test the UI will display the error message
|
||||
below the test name. To assist in the troubleshooting process, the test
|
||||
scenario is displayed under the failure message and the failed step is
|
||||
highlighted. You will find more detailed information on these tests later in
|
||||
this section.
|
||||
|
||||
An actual test run looks like this:
|
||||
|
||||
.. image:: /_images/002-health-check-results.png
|
||||
:align: center
|
||||
|
||||
What should be done when a test failed
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If a test failed, there are several ways to investigate the problem. You may
|
||||
prefer to start in Fuel UI since it's feedback is directly related to the
|
||||
health of the deployment. To do so, start by checking the following:
|
||||
|
||||
* Under the Healthcheck tab
|
||||
* In the OpenStack dashboard
|
||||
* In the test execution logs (/var/log/ostf-stdout.log)
|
||||
* In the individual OpenStack components logs
|
||||
|
||||
Of course, there are many different conditions that can lead to system
|
||||
breakdowns, but there are some simple things that can be examined before you
|
||||
dig deep. The most common issues are:
|
||||
|
||||
* Not all OpenStack services are running
|
||||
* Any defined quota has been exceeded
|
||||
* Something has broken in the network configuration
|
||||
* There is a general lack of resources (memory/disk space)
|
||||
|
||||
The first thing to be done is to ensure all OpenStack services are on. To do
|
||||
this you can run sanity test set, or execute the following command on your
|
||||
controller node:
|
||||
|
||||
.. code::
|
||||
nova-manage service list
|
||||
|
||||
If any service is off (has “XXX” status), you can restart it using this command:
|
||||
|
||||
.. code::
|
||||
service openstack-<service name> restart
|
||||
|
||||
If all services are on, but you`re still experiencing some issues, you can
|
||||
gather information on OpenStack Dashboard (exceeded number of instances,
|
||||
fixed ips etc). You may also read the logs generated by tests which is
|
||||
stored at /var/log/ostf-stdout.log, or go to /var/log/<component> and view
|
||||
if any operation has ERROR status. If it looks like the last item, you may
|
||||
have underprovisioned your environment and should check your math and your
|
||||
project requirements.
|
||||
|
||||
Sanity tests description
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Sanity checks work by sending a query to all OpenStack components to get a
|
||||
response back from them. Many of these tests are simple in that they ask
|
||||
each service for a list of it's associated objects and waits for a response.
|
||||
The response can be something, nothing, and error, or a timeout, so there
|
||||
are several ways to determine if a service is up. The following list shows
|
||||
what test is used for each service:
|
||||
|
||||
**Instances list availability**
|
||||
Test checks that Nova component can return list of instances.
|
||||
Test scenario:
|
||||
# Request list of instances.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Images list availability**
|
||||
Test checks that Glance component can return list of images.
|
||||
Test scenario:
|
||||
# Request list of images.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Volumes list availability**
|
||||
Test checks that Swift component can return list of volumes.
|
||||
Test scenario:
|
||||
# Request list of volumes.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Snapshots list availability**
|
||||
Test checks that Glance component can return list of snapshots.
|
||||
Test scenario:
|
||||
# Request list of snapshots.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Flavors list availability**
|
||||
Test checks that Nova component can return list of flavors.
|
||||
Test scenario:
|
||||
# Request list of flavors.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Limits list availability**
|
||||
Test checks that Nova component can return list of absolute limits.
|
||||
Test scenario:
|
||||
# Request list of limits.
|
||||
# Check response.
|
||||
|
||||
**Services list availability**
|
||||
Test checks that Nova component can return list of services.
|
||||
Test scenario:
|
||||
# Request list of services.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**User list availability**
|
||||
Test checks that Keystone component can return list of users.
|
||||
Test scenario:
|
||||
# Request list of services.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Services execution monitoring**
|
||||
Test checks that all of the expected services are on, meaning the test will
|
||||
fail if any of the listed services is in “XXX” status.
|
||||
Test scenario:
|
||||
# Connect to a controller via SSH.
|
||||
# Execute nova-manage service list command.
|
||||
# Check there are no failed services.
|
||||
|
||||
**DNS availability**
|
||||
Test checks that DNS is available.
|
||||
Test scenario:
|
||||
# Connect to a controller node via SSH.
|
||||
# Execute host command for the controller IP.
|
||||
# Check DNS name can be successfully resolved.
|
||||
|
||||
**Networks availability**
|
||||
Test checks that Nova component can return list of available networks.
|
||||
Test scenario:
|
||||
# Request list of networks.
|
||||
# Check returned list is not empty.
|
||||
|
||||
**Ports availability**
|
||||
Test checks that Nova component can return list of available ports.
|
||||
Test scenario:
|
||||
# Request list of ports.
|
||||
# Check returned list is not empty.
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
Smoke tests description
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Smoke tests verify how your system handles basic OpenStack operations under
|
||||
normal circumstances. The Smoke test series uses timeout tests for
|
||||
operations that have a known completion time to determine if there is any
|
||||
smoke, and thusly fire. An additional benefit to the Smoke Test series is
|
||||
that you get to see how fast your environment is the first time you run them.
|
||||
|
||||
All tests use basic OpenStack services (Nova, Glance, Keystone, Cinder etc),
|
||||
therefore if any of them is off, the test using it will fail. It is
|
||||
recommended to run all sanity checks prior to your smoke checks to determine
|
||||
all services are alive. This helps ensure that you don't get any false
|
||||
negatives. The following is a description of each sanity test available:
|
||||
|
||||
**Flavor creation**
|
||||
Test checks that low requirements flavor can be created.
|
||||
Target component: Nova
|
||||
Scenario:
|
||||
1. Create small-size flavor.
|
||||
2. Check created flavor has expected name.
|
||||
3. Check flavor disk has expected size.
|
||||
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
**Volume creation**
|
||||
Test checks that a small-sized volume can be created.
|
||||
Target component: Compute
|
||||
Scenario:
|
||||
1. Create a new small-size volume.
|
||||
2. Wait for "available" volume status.
|
||||
3. Check response contains "display_name" section.
|
||||
4. Create instance and wait for "Active" status
|
||||
5. Attach volume to instance.
|
||||
6. Check volume status is "in use".
|
||||
7. Get created volume information by its id.
|
||||
8. Detach volume from instance.
|
||||
9. Check volume has "available" status.
|
||||
10. Delete volume.
|
||||
|
||||
If you see that created volume is in ERROR status, it can mean that you`ve
|
||||
exceeded the maximum number of volumes that can be created. You can check it
|
||||
on OpenStack dashboard. For more information refer to volume management
|
||||
instructions.
|
||||
|
||||
**Instance booting and snapshotting**
|
||||
Test creates a keypair, checks that instance can be booted from default
|
||||
image, then a snapshot can be created from it and a new instance can be
|
||||
booted from a snapshot. Test also verifies that instances and images reach
|
||||
ACTIVE state upon their creation.
|
||||
Target component: Glance
|
||||
Scenario:
|
||||
1. Create new keypair to boot an instance.
|
||||
2. Boot default image.
|
||||
3. Make snapshot of created server.
|
||||
4. Boot another instance from created snapshot.
|
||||
|
||||
If you see that created instance is in ERROR status, it can mean that you`ve
|
||||
exceeded any system requirements limit. The test is using a nano-flavor with
|
||||
parameters: 64 RAM, 1 GB disk space, 1 virtual CPU presented. For more
|
||||
information refer to nova cli reference, image management instructions.
|
||||
|
||||
**Keypair creation**
|
||||
Target component: Nova.
|
||||
Scenario:
|
||||
1. Create a new keypair, check if it was created successfully
|
||||
(check name is expected, response status is 200).
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
**Security group creation**
|
||||
Target component: Nova
|
||||
Scenario:
|
||||
1. Create security group, check if it was created correctly
|
||||
(check name is expected, response status is 200).
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
**Network parameters check**
|
||||
Target component: Nova
|
||||
Scenario:
|
||||
1. Get list of networks.
|
||||
2. Check seen network labels equal to expected ones.
|
||||
3. Check seen network ids equal to expected ones.
|
||||
For more information refer to nova cli reference.
|
||||
|
||||
**Instance creation**
|
||||
Target component: Nova
|
||||
Scenario:
|
||||
1. Create new keypair (if it`s nonexistent yet).
|
||||
2. Create new sec group (if it`s nonexistent yet).
|
||||
3. Create instance with usage of created sec group and keypair.
|
||||
For more information refer to nova cli reference, instance management
|
||||
instructions.
|
||||
|
||||
**Floating IP assignment**
|
||||
Target component: Nova
|
||||
Scenario:
|
||||
1. Create new keypair (if it`s nonexistent yet).
|
||||
2. Create new sec group (if it`s nonexistent yet).
|
||||
3. Create instance with usage of created sec group and keypair.
|
||||
4. Create new floating ip.
|
||||
5. Assign floating ip to created instance.
|
||||
For more information refer to nova cli reference, floating ips management
|
||||
instructions.
|
||||
|
||||
**Network connectivity check through floating IP**
|
||||
Target component: Nova
|
||||
Scenario:
|
||||
1. Create new keypair (if it`s nonexistent yet).
|
||||
2. Create new sec group (if it`s nonexistent yet).
|
||||
3. Create instance with usage of created sec group and keypair.
|
||||
4. Check connectivity for all floating ips using ping command.
|
||||
|
||||
If this test failed, it`s better to run a network check and verify that all
|
||||
connections are correct. For more information refer to the Nova CLI reference's
|
||||
floating IPs management instructions.
|
||||
|
||||
**User creation and authentication in Horizon**
|
||||
Test creates new user, tenant, user role with admin privileges and logs in
|
||||
to dashboard. Target components: Nova, Keystone
|
||||
Scenario:
|
||||
1. Create a new tenant.
|
||||
2. Check tenant was created successfully.
|
||||
3. Create a new user.
|
||||
4. Check user was created successfully.
|
||||
5. Create a new user role.
|
||||
6. Check user role was created successfully.
|
||||
7. Perform token authentication.
|
||||
8. Check authentication was successful.
|
||||
9. Send authentication request to Horizon.
|
||||
10. Verify response status is 200.
|
||||
|
||||
If this test fails on the authentication step, you should first try opening
|
||||
the dashboard - it may be unreachable for some reason and then you should
|
||||
check your network configuration. For more information refer to nova cli
|
||||
reference.
|
||||
|
|
@ -1,9 +1,9 @@
|
|||
Overview
|
||||
--------
|
||||
========
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
Before you install any hardware or software, you must know what it is
|
||||
Before you install any hardware or software, you must know what
|
||||
you're trying to achieve. This section looks at the basic components of
|
||||
an OpenStack infrastructure and organizes them into one of the more
|
||||
common reference architectures. You'll then use that architecture as a
|
||||
|
|
@ -11,47 +11,53 @@ basis for installing OpenStack in the next section.
|
|||
|
||||
As you know, OpenStack provides the following basic services:
|
||||
|
||||
* **Compute**: Compute servers are the workhorses of your installation; they're
|
||||
the servers on which your users' virtual machines are created.
|
||||
`nova-scheduler` controls the life-cycle of these VMs.
|
||||
.. topic:: Compute:
|
||||
|
||||
* **Networking**: Because an OpenStack cluster (virtually) always includes
|
||||
multiple servers, the ability for them to communicate with each other and with
|
||||
the outside world is crucial. Networking was originally handled by the
|
||||
`nova-network` service, but it has given way to the newer Neutron (formerly
|
||||
Quantum) networking service. Authentication and authorization for these
|
||||
transactions are handled by `keystone`.
|
||||
Compute servers are the workhorses of your installation; they're
|
||||
the servers on which your users' virtual machines are created.
|
||||
`nova-scheduler` controls the life-cycle of these VMs.
|
||||
|
||||
* **Storage**: OpenStack provides for two different types of storage: block
|
||||
storage and object storage. Block storage is traditional data storage, with
|
||||
small, fixed-size blocks that are mapped to locations on storage media. At its
|
||||
simplest level, OpenStack provides block storage using `nova-volume`, but it
|
||||
is common to use `cinder`.
|
||||
|
||||
Object storage, on the other hand, consists of single variable-size objects
|
||||
that are described by system-level metadata, and you can access this capability
|
||||
using `swift`.
|
||||
.. topic:: Networking:
|
||||
|
||||
OpenStack storage is used for your users' objects, but it is also used for
|
||||
storing the images used to create new VMs. This capability is handled by `glance`.
|
||||
Because an OpenStack cluster (virtually) always includes
|
||||
multiple servers, the ability for them to communicate with each other and with
|
||||
the outside world is crucial. Networking was originally handled by the
|
||||
`nova-network` service, but it has given way to the newer Neutron (formerly
|
||||
Quantum) networking service. Authentication and authorization for these
|
||||
transactions are handled by `keystone`.
|
||||
|
||||
.. topic:: Storage:
|
||||
|
||||
OpenStack provides for two different types of storage: block
|
||||
storage and object storage. Block storage is traditional data storage, with
|
||||
small, fixed-size blocks that are mapped to locations on storage media. At its
|
||||
simplest level, OpenStack provides block storage using `nova-volume`, but it
|
||||
is common to use `cinder`.
|
||||
|
||||
Object storage, on the other hand, consists of single variable-size objects
|
||||
that are described by system-level metadata, and you can access this capability
|
||||
using `swift`.
|
||||
|
||||
OpenStack storage is used for your users' objects, but it is also used for
|
||||
storing the images used to create new VMs. This capability is handled by `glance`.
|
||||
|
||||
These services can be combined in many different ways. Out of the box,
|
||||
Fuel supports the following deployment configurations:
|
||||
|
||||
Single node deployment
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. index:: Deployment Configurations; Simple (non-HA)
|
||||
|
||||
In a production environment, you will never have a single-node
|
||||
Simple (non-HA) deployment
|
||||
--------------------------
|
||||
|
||||
In a production environment, you will never have a Simple non-HA
|
||||
deployment of OpenStack, partly because it forces you to make a number
|
||||
of compromises as to the number and types of services that you can
|
||||
deploy. It is, however, extremely useful if you just want to see how
|
||||
OpenStack works from a user's point of view. In this case, all of the
|
||||
essential services run out of a single server:
|
||||
OpenStack works from a user's point of view.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1gGNYYayPAPPHgOYi98Dmebry4hP1SOGF2APXWzbnNo8/pub?w=767&h=413
|
||||
|
||||
Multi-node (non-HA) deployment (compact Swift)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. fancybox:: /_images/deployment-simple_svg.png
|
||||
:width: 400px
|
||||
:height: 200px
|
||||
|
||||
More commonly, your OpenStack installation will consist of multiple
|
||||
servers. Exactly how many is up to you, of course, but the main idea
|
||||
|
|
@ -61,18 +67,10 @@ enable you to achieve this separation while still keeping your
|
|||
hardware investment relatively modest is to house your storage on your
|
||||
controller nodes.
|
||||
|
||||
Multi-node (non-HA) deployment (standalone Swift)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
A more common arrangement is to provide separate servers for storage.
|
||||
This has the advantage of reducing the number of controllers you must
|
||||
provide; because Swift runs on its own servers, you can reduce the
|
||||
number of controllers from three (or five, for a full Swift implementation) to one, if desired:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1nVEtfpNLaLV4EBKJQleLxovqMVrDCRT7yFWTYUQASB0/pub?w=767&h=413
|
||||
.. index:: Deployment Configurations; Compact HA
|
||||
|
||||
Multi-node (HA) deployment (Compact)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
------------------------------------
|
||||
|
||||
Production environments typically require high availability, which
|
||||
involves several architectural requirements. Specifically, you will
|
||||
|
|
@ -82,38 +80,28 @@ single points of failure. That's not to say, however, that you can't
|
|||
reduce hardware requirements by combining your storage, network, and controller
|
||||
nodes:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1xLv4zog19j0MThVGV9gSYa4wh1Ma4MQYsBz-4vE1xvg/pub?w=767&h=413
|
||||
.. fancybox:: /_images/deployment-ha-compact_svg.png
|
||||
:width: 400px
|
||||
:height: 250px
|
||||
|
||||
Multi-node (HA) deployment (Compact Neutron)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. index:: Deployment Configurations; Full HA
|
||||
|
||||
Another way you can add functionality to your cluster without
|
||||
increasing hardware requirements is to install Quantum on your
|
||||
controller nodes. This architecture still provides high availability,
|
||||
but avoids the need for a separate Neutron node:
|
||||
Multi-node (HA) deployment (Full)
|
||||
---------------------------------
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1GYNM5yTJSlZe9nB5SHnlrqyMfVRdVh02OFLwXlz-itc/pub?w=767&h=413
|
||||
For large production deployments, its more common to provide
|
||||
dedicated hardware for storage. This architecture gives you the advantages of
|
||||
high availability, but this clean separation makes your cluster more
|
||||
maintainable by separating storage and controller functionality:
|
||||
|
||||
Multi-node (HA) deployment (Standalone)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. fancybox:: /_images/deployment-ha-full_svg.png
|
||||
:width: 400px
|
||||
:height: 200px
|
||||
|
||||
For larger production deployments, its more common to provide
|
||||
dedicated hardware for storage and networking. This architecture still
|
||||
gives you the advantages of high availability, but this clean
|
||||
separation makes your cluster more maintainable by separating storage,
|
||||
networking, and controller functionality:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1rJEZi5-l9oemMmrkH5UPjitQQDVGuZQ1KS0pPWTuovY/pub?w=769&h=594
|
||||
|
||||
Where Fuel really shines is in the creation of more complex
|
||||
architectures, so in this document you'll learn how to use Fuel to
|
||||
easily create a multi-node HA OpenStack cluster. To reduce the amount
|
||||
of hardware you'll need to follow the installation in section 3,
|
||||
however, the guide focuses on the Multi-node HA Compact
|
||||
Where Fuel really shines is in the creation of more complex architectures, so
|
||||
in this document you'll learn how to use Fuel to easily create a multi-node HA
|
||||
OpenStack cluster. To reduce the amount of hardware you'll need to follow the
|
||||
installation, however, the guide focuses on the Multi-node HA Compact
|
||||
architecture.
|
||||
|
||||
|
||||
|
||||
Lets take a closer look at the details of this deployment configuration.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,13 @@
|
|||
A closer look at the Multi-node (HA) Compact deployment
|
||||
-------------------------------------------------------
|
||||
=======================================================
|
||||
|
||||
In this section, you'll learn more about the Multi-node (HA) Compact
|
||||
deployment configuration and how it achieves high availability in preparation
|
||||
for installing this cluster in section 3. As you may recall, this
|
||||
configuration looks something like this:
|
||||
deployment configuration and how it achieves high availability. As you may
|
||||
recall, this configuration looks something like this:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/d/1xLv4zog19j0MThVGV9gSYa4wh1Ma4MQYsBz-4vE1xvg/pub?w=767&h=413
|
||||
.. fancybox:: /_images/deployment-ha-compact_svg.png
|
||||
:width: 400px
|
||||
:height: 250px
|
||||
|
||||
OpenStack services are interconnected by RESTful HTTP-based APIs and
|
||||
AMQP-based RPC messages. So redundancy for stateless OpenStack API
|
||||
|
|
@ -17,7 +18,9 @@ rely on their respective active/active modes for high availability.
|
|||
For example, RabbitMQ uses built-in clustering capabilities, while the
|
||||
database uses MySQL/Galera replication.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1PzRBUaZEPMG25488mlb42fRdlFS3BygPwbAGBHudnTM&w=750&h=491
|
||||
.. fancybox:: /_images/ha-overview_svg.png
|
||||
:width: 400px
|
||||
:height: 250px
|
||||
|
||||
Lets take a closer look at what an OpenStack deployment looks like, and
|
||||
what it will take to achieve high availability for an OpenStack
|
||||
|
|
|
|||
|
|
@ -1,33 +1,31 @@
|
|||
|
||||
Logical Setup
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
=============
|
||||
.. contents:: :local:
|
||||
|
||||
An OpenStack HA cluster involves, at a minimum, three types of nodes:
|
||||
controller nodes, compute nodes, and storage nodes.
|
||||
|
||||
Controller Nodes
|
||||
++++++++++++++++
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
The first order of business in achieving high availability (HA) is
|
||||
redundancy, so the first step is to provide multiple controller nodes.
|
||||
You must keep in mind, however, that the database uses Galera to
|
||||
achieve HA, and Galera is a quorum-based system. That means that you must provide at least 3
|
||||
controller nodes.
|
||||
achieve HA, and Galera is a quorum-based system. That means that you must provide
|
||||
at least 3 controller nodes.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1aftE8Yes7CdVSZgZD1A82T_2GqL2SMImtRYU914IMyQ&w=869&h=855
|
||||
.. fancybox:: /_images/logical-diagram-controller_svg.png
|
||||
:width: 400px
|
||||
:height: 400px
|
||||
|
||||
|
||||
Every OpenStack controller runs keepalived, which manages a single
|
||||
Virtual IP (VIP) for all controller nodes, and HAProxy, which manages
|
||||
HTTP and TCP load balancing of requests going to OpenStack API
|
||||
services, RabbitMQ, and MySQL.
|
||||
Every OpenStack controller runs HAProxy, which manages a single External
|
||||
Virtual IP (VIP) for all controller nodes and provides HTTP and TCP load
|
||||
balancing of requests going to OpenStack API services, RabbitMQ, and MySQL.
|
||||
|
||||
When an end user accesses the OpenStack cloud using Horizon or makes a
|
||||
request to the REST API for services such as nova-api, glance-api,
|
||||
keystone-api, quantum-api, nova-scheduler, MySQL or RabbitMQ, the
|
||||
request goes to the live controller node currently holding the VIP,
|
||||
request goes to the live controller node currently holding the External VIP,
|
||||
and the connection gets terminated by HAProxy. When the next request
|
||||
comes in, HAProxy handles it, and may send it to the original
|
||||
controller or another in the cluster, depending on load conditions.
|
||||
|
|
@ -35,13 +33,18 @@ controller or another in the cluster, depending on load conditions.
|
|||
Each of the services housed on the controller nodes has its own
|
||||
mechanism for achieving HA:
|
||||
|
||||
* nova-api, glance-api, keystone-api, quantum-api and nova-scheduler are stateless services that do not require any special attention besides load balancing.
|
||||
* Horizon, as a typical web application, requires sticky sessions to be enabled at the load balancer.
|
||||
* nova-api, glance-api, keystone-api, quantum-api and nova-scheduler are
|
||||
stateless services that do not require any special attention besides load
|
||||
balancing.
|
||||
* Horizon, as a typical web application, requires sticky sessions to be enabled
|
||||
at the load balancer.
|
||||
* RabbitMQ provides active/active high availability using mirrored queues.
|
||||
* MySQL high availability is achieved through Galera active/active multi-master deployment.
|
||||
* MySQL high availability is achieved through Galera active/active multi-master
|
||||
deployment and Pacemaker.
|
||||
* Quantum agents are managed by Pacemaker.
|
||||
|
||||
Compute Nodes
|
||||
+++++++++++++
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
OpenStack compute nodes are, in many ways, the foundation of your
|
||||
cluster; they are the servers on which your users will create their
|
||||
|
|
@ -51,10 +54,12 @@ as RabbitMQ and MySQL. They use the same approach that provides
|
|||
redundancy to the end-users of Horizon and REST APIs, reaching out to
|
||||
controller nodes using the VIP and going through HAProxy.
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=16gsjc81Ptb5SL090XYAN8Kunrxfg6lScNCo3aReqdJI&w=873&h=801
|
||||
.. fancybox:: /_images/logical-diagram-compute_svg.png
|
||||
:width: 400px
|
||||
:height: 180px
|
||||
|
||||
Storage Nodes
|
||||
+++++++++++++
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
In this OpenStack cluster reference architecture, shared storage acts
|
||||
as a backend for Glance, so that multiple Glance instances running on
|
||||
|
|
@ -63,6 +68,6 @@ achieve this, you are going to deploy Swift. This enables you to use
|
|||
it not only for storing VM images, but also for any other objects such
|
||||
as user files.
|
||||
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1Xd70yy7h5Jq2oBJ12fjnPWP8eNsWilC-ES1ZVTFo0m8&w=777&h=778
|
||||
|
||||
.. fancybox:: /_images/logical-diagram-storage_svg.png
|
||||
:width: 400px
|
||||
:height: 200px
|
||||
|
|
|
|||
|
|
@ -1,6 +1,7 @@
|
|||
.. index:: Cluster Sizing
|
||||
|
||||
Cluster Sizing
|
||||
^^^^^^^^^^^^^^
|
||||
==============
|
||||
|
||||
This reference architecture is well suited for production-grade
|
||||
OpenStack deployments on a medium and large scale when you can afford
|
||||
|
|
@ -10,18 +11,28 @@ order to build a fully redundant and highly available environment.
|
|||
The absolute minimum requirement for a highly-available OpenStack
|
||||
deployment is to allocate 4 nodes:
|
||||
|
||||
* 3 controller nodes, combined with storage
|
||||
* 1 compute node
|
||||
- 3 controller nodes, combined with storage
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=19Dk1qD5V50-N0KX4kdG_0EhGUBP7D_kLi2dU6caL9AM&w=767&h=413
|
||||
- 1 compute node
|
||||
|
||||
If you want to run storage separately from the controllers, you can do that as well by raising the bar to 7 nodes:
|
||||
.. fancybox:: /_images/deployment-ha-compact_svg.png
|
||||
:width: 400px
|
||||
:height: 250px
|
||||
|
||||
* 3 controller nodes
|
||||
* 3 storage nodes
|
||||
* 1 compute node
|
||||
If you want to run storage separately from the controllers, you can do that as
|
||||
well by raising the bar to 9 nodes:
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=1xmGUrk2U-YWmtoS77xqG0tzO3A47p6cI3mMbzLKG8tY&w=769&h=594
|
||||
- 3 Controller nodes
|
||||
|
||||
- 3 Storage nodes
|
||||
|
||||
- 2 Swift Proxy nodes
|
||||
|
||||
- 1 Compute node
|
||||
|
||||
.. fancybox:: /_images/deployment-ha-full_svg.png
|
||||
:width: 400px
|
||||
:height: 200px
|
||||
|
||||
Of course, you are free to choose how to deploy OpenStack based on the
|
||||
amount of available hardware and on your goals (such as whether you
|
||||
|
|
@ -31,11 +42,14 @@ For a typical OpenStack compute deployment, you can use this table as
|
|||
high-level guidance to determine the number of controllers, compute,
|
||||
and storage nodes you should have:
|
||||
|
||||
============= =========== ======= ==============
|
||||
# of Machines Controllers Compute Storage
|
||||
============= =========== ======= ==============
|
||||
4-10 3 1-7 on controllers
|
||||
11-40 3 5-34 3 (separate)
|
||||
41-100 4 31-90 6 (separate)
|
||||
>100 5 >86 9 (separate)
|
||||
============= =========== ======= ==============
|
||||
+----------+-----------+--------+-----------------------+
|
||||
|# of Nodes|Controllers|Computes|Storages |
|
||||
+==========+===========+========+=======================+
|
||||
|4-10 | 3 | 1-7 |3 (on controllers) |
|
||||
+----------+-----------+--------+-----------------------+
|
||||
|11-40 | 3 | 3-32 |3+ (swift) + 2 (proxy) |
|
||||
+----------+-----------+--------+-----------------------+
|
||||
|41-100 | 4 | 29-88 |6+ (swift) + 2 (proxy) |
|
||||
+----------+-----------+--------+-----------------------+
|
||||
|>100 | 5 | >84 |9+ (swift) + 2 (proxy) |
|
||||
+----------+-----------+--------+-----------------------+
|
||||
|
|
|
|||
|
|
@ -1,46 +1,80 @@
|
|||
.. index:: Network Architecture
|
||||
|
||||
Network Architecture
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
====================
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
The current architecture assumes the presence of 3 NIC cards in hardware, but can be customized two or more NICs. Most servers come with at least two network interfaces. In this case, let's consider a typical example of three NIC cards. They're utilized as follows:
|
||||
The current architecture assumes the presence of 3 NICs, but it can be
|
||||
customized for two or 4+ network interfaces. Most servers arebuilt with at least
|
||||
two network interfaces. In this case, let's consider a typical example of three
|
||||
NIC cards. They're utilized as follows:
|
||||
|
||||
* **eth0**: the internal management network, used for communication with Puppet & Cobbler
|
||||
* **eth1**: the public network, and floating IPs assigned to VMs
|
||||
* **eth2**: the private network, for communication between OpenStack VMs, and the bridge interface (VLANs)
|
||||
- **eth0**: the internal management network, used for communication with Puppet & Cobbler
|
||||
|
||||
In the multi-host networking mode, you can choose between the FlatDHCPManager and VlanManager network managers in OpenStack. The figure below illustrates the relevant nodes and networks.
|
||||
- **eth1**: the public network, and floating IPs assigned to VMs
|
||||
|
||||
.. image:: https://docs.google.com/drawings/pub?id=11KtrvPxqK3ilkAfKPSVN5KzBjnSPIJw-jRDc9fiYhxw&w=810&h=1060
|
||||
- **eth2**: the private network, for communication between OpenStack VMs, and the
|
||||
bridge interface (VLANs)
|
||||
|
||||
In the multi-host networking mode, you can choose between the FlatDHCPManager
|
||||
and VlanManager network managers in OpenStack. The figure below illustrates the
|
||||
relevant nodes and networks.
|
||||
|
||||
.. fancybox:: /_images/080-networking-diagram_svg.png
|
||||
:width: 400px
|
||||
:height: 500px
|
||||
|
||||
Lets take a closer look at each network and how its used within the cluster.
|
||||
|
||||
Public Network
|
||||
++++++++++++++
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
This network allows inbound connections to VMs from the outside world (allowing users to connect to VMs from the Internet). It also allows outbound connections from VMs to the outside world.
|
||||
This network allows inbound connections to VMs from the outside world (allowing
|
||||
users to connect to VMs from the Internet). It also allows outbound connections
|
||||
from VMs to the outside world.
|
||||
|
||||
For security reasons, the public network is usually isolated from the private network and internal (management) network. Typically, it's a single C class network from your globally routed or private network range.
|
||||
For security reasons, the public network is usually isolated from the private
|
||||
network and internal (management) network. Typically, it's a single C class
|
||||
network from your globally routed or private network range.
|
||||
|
||||
To enable Internet access to VMs, the public network provides the address space for the floating IPs assigned to individual VM instances by the project administrator. Nova-network or Neutron (formerly Quantum) services can then configure this address on the public network interface of the Network controller node. If the cluster uses nova-network, nova- network uses iptables to create a Destination NAT from this address to the fixed IP of the corresponding VM instance through the appropriate virtual bridge interface on the Network controller node.
|
||||
To enable Internet access to VMs, the public network provides the address space
|
||||
for the floating IPs assigned to individual VM instances by the project
|
||||
administrator. Nova-network or Neutron (formerly Quantum) services can then
|
||||
configure this address on the public network interface of the Network controller
|
||||
node. Clusters based on nova-network use iptables to create a
|
||||
Destination NAT from this address to the fixed IP of the corresponding VM
|
||||
instance through the appropriate virtual bridge interface on the Network
|
||||
controller node.
|
||||
|
||||
In the other direction, the public network provides connectivity to the globally routed address space for VMs. The IP address from the public network that has been assigned to a compute node is used as the source for the Source NAT performed for traffic going from VM instances on the compute node to Internet.
|
||||
In the other direction, the public network provides connectivity to the globally
|
||||
routed address space for VMs. The IP address from the public network that has
|
||||
been assigned to a compute node is used as the source for the Source NAT
|
||||
performed for traffic going from VM instances on the compute node to Internet.
|
||||
|
||||
The public network also provides VIPs for Endpoint nodes, which are used to connect to OpenStack services APIs.
|
||||
The public network also provides VIPs for Endpoint nodes, which are used to
|
||||
connect to OpenStack services APIs.
|
||||
|
||||
Internal (Management) Network
|
||||
+++++++++++++++++++++++++++++
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The internal network connects all OpenStack nodes in the cluster. All components of an OpenStack cluster communicate with each other using this network. This network must be isolated from both the private and public networks for security reasons.
|
||||
The internal network connects all OpenStack nodes in the cluster. All components
|
||||
of an OpenStack cluster communicate with each other using this network. This
|
||||
network must be isolated from both the private and public networks for security
|
||||
reasons.
|
||||
|
||||
The internal network can also be used for serving iSCSI protocol exchanges between Compute and Storage nodes.
|
||||
The internal network can also be used for serving iSCSI protocol exchanges
|
||||
between Compute and Storage nodes.
|
||||
|
||||
This network usually is a single C class network from your private, non-globally routed IP address range.
|
||||
This network usually is a single C class network from your private, non-globally
|
||||
routed IP address range.
|
||||
|
||||
Private Network
|
||||
+++++++++++++++
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
The private network facilitates communication between each tenant's VMs. Private network address spaces are part of the enterprise network address space. Fixed IPs of virtual instances are directly accessible from the rest of Enterprise network.
|
||||
The private network facilitates communication between each tenant's VMs. Private
|
||||
network address spaces are part of the enterprise network address space. Fixed
|
||||
IPs of virtual instances are directly accessible from the rest of Enterprise network.
|
||||
|
||||
The private network can be segmented into separate isolated VLANs, which are managed by nova-network or Neutron (formerly Quantum) services.
|
||||
The private network can be segmented into separate isolated VLANs, which are
|
||||
managed by nova-network or Neutron (formerly Quantum) services.
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
Technical Considerations
|
||||
----------------------------
|
||||
========================
|
||||
|
||||
Before performing any installations, you'll need to make a number of
|
||||
decisions about which services to deploy, but from a general
|
||||
|
|
|
|||
|
|
@ -1,11 +1,21 @@
|
|||
|
||||
Neutron vs. nova-network
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Neutron (formerly Quantum) is a service which provides networking-as-a-service functionality in OpenStack. It has a rich tenant-facing API for defining network connectivity and addressing in the cloud, and gives operators the ability to leverage different networking technologies to power their cloud networking.
|
||||
Neutron (formerly Quantum) is a service which provides networking-as-a-service
|
||||
functionality in OpenStack. It has a rich tenant-facing API for defining network
|
||||
connectivity and addressing in the cloud, and gives operators the ability to
|
||||
leverage different networking technologies to power their cloud networking.
|
||||
|
||||
There are various deployment use cases for Neutron. Fuel supports the most common of them, called Provider Router with Private Networks. It provides each tenant with one or more private networks, which can communicate with the outside world via a Neutron router.
|
||||
There are various deployment use cases for Neutron. Fuel supports the most
|
||||
common of them, called Provider Router with Private Networks. It provides each
|
||||
tenant with one or more private networks, which can communicate with the outside
|
||||
world via a Neutron router.
|
||||
|
||||
Neutron is not, however, required in order to run an OpenStack cluster; if you don't need (or want) this added functionality, it's perfectly acceptable to continue using nova-network.
|
||||
Neutron is not, however, required in order to run an OpenStack cluster. If you
|
||||
don't need (or want) this added functionality, it's perfectly acceptable to
|
||||
continue using nova-network.
|
||||
|
||||
In order to deploy Neutron, you need to enable it in the Fuel configuration. Fuel will then set up an additional node in the OpenStack installation to act as an L3 router, or, depending on the configuration options you've chosen, install Neutron on the controllers.
|
||||
In order to deploy Neutron, you need to enable it in the Fuel configuration.
|
||||
Fuel will then set up an additional node in the OpenStack installation to act
|
||||
as an L3 router, or, depending on the configuration options you've chosen,
|
||||
install Neutron on the controllers.
|
||||
|
|
@ -1,26 +1,17 @@
|
|||
|
||||
Cinder vs. nova-volume
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Cinder is a persistent storage management service, also known as block-storage-as-a-service. It was created to replace nova-volume, and
|
||||
Cinder is a persistent storage management service, also known as
|
||||
block-storage-as-a-service. It was created to replace nova-volume, and
|
||||
provides persistent storage for VMs.
|
||||
|
||||
|
||||
|
||||
If you decide use Cinder for persistent storage, you will need to both
|
||||
If you want to use Cinder for persistent storage, you will need to both
|
||||
enable Cinder and create the block devices on which it will store data.
|
||||
You will then provide information about those blocks devices during the Fuel
|
||||
install. (You'll see an example how to do this in section 3.)
|
||||
|
||||
|
||||
install.
|
||||
|
||||
Cinder block devices can be:
|
||||
|
||||
|
||||
* created by Cobbler during the initial node installation, or
|
||||
* attached manually (e.g. as additional virtual disks if you are using VirtualBox, or as additional physical RAID, SAN volumes)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
* attached manually (e.g. as additional virtual disks if you are using
|
||||
VirtualBox, or as additional physical RAID, SAN volumes)
|
||||
|
|
|
|||
|
|
@ -1,21 +1,28 @@
|
|||
.. index:: Object storage, Swift
|
||||
|
||||
.. _Swift-and-object-storage-notes:
|
||||
|
||||
Swift (object storage) notes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
Object storage deployment notes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
FUEL currently supports several ways to deploy the swift service:
|
||||
Fuel currently supports several scenarios to deploy the object storage:
|
||||
|
||||
* Swift absent
|
||||
* Glance + filesystem
|
||||
|
||||
By default, Glance uses the filesystem backend to store virtual machine images. In this case, you can use any of shared file systems Glance supports.
|
||||
By default, Glance uses the file system backend to store virtual machine images.
|
||||
In this case, you can use any of shared file systems supported by Glance.
|
||||
|
||||
* Swift compact
|
||||
* Swift on controllers
|
||||
|
||||
In this mode the role of swift-storage and swift-proxy are combined with a nova-controller. Use it only for testing in order to save nodes; it's not suitable for production.
|
||||
In this mode the role of swift-storage and swift-proxy are combined with a
|
||||
nova-controller. Use it only for testing in order to save nodes. It's not
|
||||
suitable for production environments.
|
||||
|
||||
* Swift standalone
|
||||
* Swift on dedicated nodes
|
||||
|
||||
In this case the Proxy service and Storage (account/container/object) services reside on separate nodes, with one proxy node and a minimum of three storage nodes. (For a production cluster, a minimum of five nodes is recommended.)
|
||||
In this case the Proxy service and Storage (account/container/object) services
|
||||
reside on separate nodes, with two proxy nodes and a minimum of three storage
|
||||
nodes.
|
||||
|
||||
Now let's look at performing an actual OpenStack installation using Fuel.
|
||||
Now let's look at performing an actual OpenStack deployment using Fuel.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
.. index:: Release Notes; v1.0-essex
|
||||
|
||||
.. _RelNotes_1.0:
|
||||
|
||||
v1.0-essex
|
||||
^^^^^^^^^^
|
||||
==========
|
||||
|
||||
* Features:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
.. index:: Release Notes; v2.0-folsom
|
||||
|
||||
.. _RelNotes_2.0:
|
||||
|
||||
v2.0-folsom
|
||||
^^^^^^^^^^^
|
||||
===========
|
||||
|
||||
* Features:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,9 @@
|
|||
.. index:: Release Notes; v2.1-folsom
|
||||
|
||||
.. _RelNotes_2.1:
|
||||
|
||||
v2.1-folsom
|
||||
^^^^^^^^^^^
|
||||
===========
|
||||
|
||||
* Features
|
||||
|
||||
|
|
|
|||
|
|
@ -1,17 +0,0 @@
|
|||
|
||||
v2.2-folsom
|
||||
^^^^^^^^^^^
|
||||
|
||||
* Features
|
||||
|
||||
* NIC Bonding support
|
||||
* New firewall (iptables) module
|
||||
* One-pass swift deployment
|
||||
* User choice on where to store Cinder volumes
|
||||
* Ability to plug in custom services in HA mode under HAProxy
|
||||
* Add controller and compute nodes without downtime
|
||||
* Remove controller and compute nodes without downtime *(caveat with Cinder on controllers)*
|
||||
|
||||
* Improvements
|
||||
|
||||
* CentOS 6.3 package repository moved to Mirantis mirror
|
||||
|
|
@ -1,5 +1,9 @@
|
|||
.. index:: Release Notes; v3.0-grizzly
|
||||
|
||||
.. _RelNotes_3.0:
|
||||
|
||||
v3.0-grizzly
|
||||
^^^^^^^^^^^^
|
||||
============
|
||||
|
||||
**New Features in Fuel and FuelWeb 3.0**
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,78 @@
|
|||
.. index:: Release Notes; v3.1-grizzly
|
||||
|
||||
.. _RelNotes_3.1:
|
||||
|
||||
v3.1-grizzly
|
||||
^^^^^^^^^^^^
|
||||
============
|
||||
|
||||
**New Features in Fuel and FuelWeb 3.1**
|
||||
New Features in Fuel 3.1
|
||||
-------------------------
|
||||
|
||||
PLACEHOLDER
|
||||
.. contents:: :local:
|
||||
|
||||
* Combined Fuel library and Fuel Web products
|
||||
* Option to deploy Red Hat Enterprise Linux® OpenStack® Platform
|
||||
* Mirantis OpenStack Health Check
|
||||
* Ability to deploy properly in networks that are not utilizing VLAN tagging
|
||||
* Integrated ability to connect to remote nodes via SSH
|
||||
* Improved High Availability resiliency
|
||||
|
||||
Fuel 3.1 with Integrated graphical and command line controls
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In earlier releases, Fuel was distributed as two packages – “Fuel Web” for
|
||||
graphical workflow, and “Fuel library” for command-line based manipulation.
|
||||
Starting with this 3.1 release, we’ve integrated these two capabilities into a
|
||||
single offering, referred to simply as Fuel. If you used Fuel Web, you’ll see
|
||||
that capability along with its latest improvements to that capability in the the
|
||||
Fuel User Interface (UI), providing a streamlined, graphical console that enables
|
||||
a point-and-click experience for the most commonly deployed configurations.
|
||||
Advanced users with more complex environmental needs can still get command-line
|
||||
access to the underlying deployment engine (aka “Fuel Library”).
|
||||
|
||||
Option to deploy Red Hat Enterprise Linux® OpenStack® Platform
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Mirantis Fuel now includes the ability to deploy the Red Hat Enterprise Linux
|
||||
OpenStack Platform (a solution that includes both Red Hat Enterprise Linux and
|
||||
the Red Hat OpenStack distribution). During the definition of a new environment,
|
||||
the user will be presented with the option of either installing the Mirantis
|
||||
provided OpenStack distribution onto CentOS powered nodes or installing the Red
|
||||
Hat provided OpenStack distribution onto Red Hat Enterprise Linux powered nodes.
|
||||
|
||||
.. note:: A Red Hat subscription is required to download and deploy Red Hat
|
||||
Enterprise Linux OpenStack Platform.
|
||||
|
||||
Mirantis OpenStack Health Check
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
New in this release is the Mirantis OpenStack Health Check which can be accessed
|
||||
through a tab in the Fuel UI. The OpenStack HealthCheck is a battery of tests
|
||||
that can be run against an OpenStack deployment to ensure that it is installed
|
||||
properly and operating correctly. The suite of tests exercise not only the core
|
||||
components within OpenStack, but also the added packages included in the Mirantis
|
||||
OpenStack distribution. Tests can be run individually or in groups. A full list
|
||||
of available tests can be found in the documentation.
|
||||
|
||||
Ability to deploy properly in networks that are not utilizing VLAN tagging
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In some environments, it may not be possible or desired to utilize VLANs to
|
||||
segregate network traffic. In these networks, Fuel can now be configured through
|
||||
the Fuel UI to disable the need for VLAN tagging. This configuration option is
|
||||
available through the Network Settings tab.
|
||||
|
||||
Integrated ability to connect to remote nodes via SSH
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The ability to connect to a remote node via SSH is now available from the machine
|
||||
details screen. SSH key management is automatically handled by Fuel, so the user
|
||||
need only click on she SSH Console button to connect.
|
||||
|
||||
Improved High Availability resiliency
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To improve the resiliency of the Mirantis OpenStack High Availability reference
|
||||
architecture, Fuel now deploys all HA services under Pacemaker, a scalable
|
||||
cluster resource manager developed by Clusterlabs. Additional options in the
|
||||
Fuel Library have also been added to Corosync to enable more granular tuning.
|
||||
|
|
|
|||
Loading…
Reference in New Issue