Docs: Add RDO-Manager Architecture chapter
First draft combining: * https://www.rdoproject.org/RDO_Manager_Architecture_Overview * https://github.com/rbrady/tripleo/blob/master/docs/architecture_overview.rst and adding RDO-Manager context. I will need help with the Per-node Setup (aka Puppet) section. Change-Id: I14efd1fe0b507c8d72f49c25b6bcf16a7961e891
This commit is contained in:
Jaromir Coufal
parent
46f6fe1f7f
commit
8f88e1aac4
|
|
@ -218,9 +218,9 @@ a.external:after {
|
|||
|
||||
|
||||
/* LIST */
|
||||
.wy-plain-list-decimal li ul,
|
||||
.rst-content .section ol li ul,
|
||||
.rst-content ol.arabic li ul,
|
||||
article ol li ul {
|
||||
.wy-plain-list-decimal > li > ul,
|
||||
.rst-content .section ol > li > ul,
|
||||
.rst-content ol.arabic > li > ul,
|
||||
article ol > li > ul {
|
||||
margin-bottom: 24px;
|
||||
}
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 62 KiB |
|
|
@ -0,0 +1,192 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
width="1075.511px" height="793.5px" viewBox="1020 0 1075.511 793.5" enable-background="new 1020 0 1075.511 793.5"
|
||||
xml:space="preserve">
|
||||
<g>
|
||||
<rect x="1046.5" y="42.271" fill="#FFFFFF" width="230.863" height="82.729"/>
|
||||
<g>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1277.363,122 1277.363,125 1274.363,125 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1268.286" y1="125" x2="1052.539" y2="125"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1049.5,125 1046.5,125 1046.5,122 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1046.5" y1="116.098" x2="1046.5" y2="48.222"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1046.5,45.271 1046.5,42.271 1049.5,42.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1055.577" y1="42.271" x2="1271.324" y2="42.271"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1274.363,42.271 1277.363,42.271 1277.363,45.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1277.363" y1="51.173" x2="1277.363" y2="119.049"/>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1048.5" y="73.745" fill="none" width="228.863" height="21.781"/>
|
||||
<text transform="matrix(1 0 0 1 1138.9512 87.4243)" font-family="'OpenSans'" font-size="18">Client</text>
|
||||
<g>
|
||||
<rect x="1310.675" y="42.271" fill="#FFFFFF" width="230.863" height="82.729"/>
|
||||
<g>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1541.538,122 1541.538,125 1538.538,125 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1532.461" y1="125" x2="1316.714" y2="125"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1313.675,125 1310.675,125 1310.675,122 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1310.675" y1="116.097" x2="1310.675" y2="48.222"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1310.675,45.271 1310.675,42.271 1313.675,42.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1319.752" y1="42.271" x2="1535.499" y2="42.271"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1538.538,42.271 1541.538,42.271 1541.538,45.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1541.538" y1="51.173" x2="1541.538" y2="119.048"/>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1310.675" y="73.745" fill="none" width="230.863" height="21.781"/>
|
||||
<text transform="matrix(1 0 0 1 1402.4023 87.4243)" font-family="'OpenSans'" font-size="18">Ironic</text>
|
||||
<g>
|
||||
<rect x="1577.004" y="43.271" fill="#FFFFFF" width="230.863" height="82.729"/>
|
||||
<g>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1807.867,123 1807.867,126 1804.867,126 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1798.79" y1="126" x2="1583.043" y2="126"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1580.004,126 1577.004,126 1577.004,123 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1577.004" y1="117.097" x2="1577.004" y2="49.222"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1577.004,46.271 1577.004,43.271 1580.004,43.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1586.081" y1="43.271" x2="1801.828" y2="43.271"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1804.867,43.271 1807.867,43.271 1807.867,46.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1807.867" y1="52.173" x2="1807.867" y2="120.048"/>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1578.582" y="74.745" fill="none" width="230.863" height="21.781"/>
|
||||
<text transform="matrix(1 0 0 1 1615.3076 88.4243)" font-family="'OpenSans'" font-size="18">Discovery Ramdisk</text>
|
||||
<g>
|
||||
<rect x="1837.637" y="42.271" fill="#FFFFFF" width="230.863" height="82.729"/>
|
||||
<g>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="2068.5,122 2068.5,125 2065.5,125 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="2059.423" y1="125" x2="1843.676" y2="125"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1840.637,125 1837.637,125 1837.637,122 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="1837.637" y1="116.097" x2="1837.637" y2="48.222"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="1837.637,45.271 1837.637,42.271 1840.637,42.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="6.0774,6.0774" x1="1846.714" y1="42.271" x2="2062.461" y2="42.271"/>
|
||||
<polyline fill="none" stroke="#000000" stroke-miterlimit="10" points="2065.5,42.271 2068.5,42.271 2068.5,45.271 "/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-miterlimit="10" stroke-dasharray="5.9022,5.9022" x1="2068.5" y1="51.173" x2="2068.5" y2="119.048"/>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1835.637" y="73.745" fill="none" width="232.863" height="21.781"/>
|
||||
<text transform="matrix(1 0 0 1 1910.4697 87.4243)" font-family="'OpenSans'" font-size="18">Discoverd</text>
|
||||
<g>
|
||||
<g>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1161.932" y1="126" x2="1161.932" y2="132"/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1161.932" y1="144.193" x2="1161.932" y2="723.403"/>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1161.932" y1="729.5" x2="1161.932" y2="735.5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1426.106" y1="126" x2="1426.106" y2="132"/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1426.106" y1="144.193" x2="1426.106" y2="723.403"/>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1426.106" y1="729.5" x2="1426.106" y2="735.5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1692.436" y1="126" x2="1692.436" y2="132"/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1692.436" y1="144.193" x2="1692.436" y2="723.403"/>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1692.436" y1="729.5" x2="1692.436" y2="735.5"/>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1953.068" y1="126" x2="1953.068" y2="132"/>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" stroke-dasharray="12.1939,12.1939" x1="1953.068" y1="144.193" x2="1953.068" y2="723.403"/>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-miterlimit="10" x1="1953.068" y1="729.5" x2="1953.068" y2="735.5"/>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1156.932" y="169.729" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="537.771"/>
|
||||
<rect x="1420.106" y="169.729" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="158.771"/>
|
||||
<rect x="1420.106" y="386" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="319.635"/>
|
||||
<rect x="1946.068" y="612.5" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="92.089"/>
|
||||
<g>
|
||||
<g>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1182.5" y1="169.729" x2="1394.43" y2="169.729"/>
|
||||
<g>
|
||||
<path d="M1406.5,169.729c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.51
|
||||
C1393.773,164.028,1400.82,167.624,1406.5,169.729z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1182.5" y1="383.729" x2="1394.43" y2="383.729"/>
|
||||
<g>
|
||||
<path d="M1406.5,383.729c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.509
|
||||
C1393.773,378.027,1400.82,381.623,1406.5,383.729z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1706.5" y1="612.5" x2="1918.43" y2="612.5"/>
|
||||
<g>
|
||||
<path d="M1930.5,612.5c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.51
|
||||
C1917.773,606.799,1924.82,610.395,1930.5,612.5z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1686.436" y="386" fill="#820E0A" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" width="12" height="226.5"/>
|
||||
<g>
|
||||
<g>
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1450.436" y1="386" x2="1662.365" y2="386"/>
|
||||
<g>
|
||||
<path d="M1674.436,386c-5.68,2.107-12.727,5.703-17.095,9.512l3.44-9.512l-3.44-9.51
|
||||
C1661.709,380.299,1668.756,383.895,1674.436,386z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<g>
|
||||
<g>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1460.506" y1="704.589" x2="1930.5" y2="704.589"/>
|
||||
<g>
|
||||
<path d="M1448.436,704.589c5.68,2.107,12.727,5.703,17.095,9.512l-3.44-9.512l3.44-9.51
|
||||
C1461.162,698.888,1454.115,702.483,1448.436,704.589z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1180.068" y="134.706" fill="none" width="228.863" height="33.317"/>
|
||||
<text transform="matrix(1 0 0 1 1180.0684 145.3457)"><tspan x="0" y="0" font-family="'OpenSans'" font-size="14">Register nodes’</tspan><tspan x="0" y="16.8" font-family="'OpenSans'" font-size="14">power management details</tspan></text>
|
||||
<rect x="1182.5" y="348.047" fill="none" width="228.863" height="33.316"/>
|
||||
<text transform="matrix(1 0 0 1 1182.5 375.4868)" font-family="'OpenSans'" font-size="14">Send nodes for introspection</text>
|
||||
<rect x="1448.004" y="350.047" fill="none" width="228.863" height="33.316"/>
|
||||
<text transform="matrix(1 0 0 1 1448.0039 360.687)"><tspan x="0" y="0" font-family="'OpenSans'" font-size="14">Reboot nodes -> PXE boot generic </tspan><tspan x="0" y="16.799" font-family="'OpenSans'" font-size="14">discovery ramdisk image</tspan></text>
|
||||
<rect x="1584.004" y="669.545" fill="none" width="346.496" height="33.316"/>
|
||||
<text transform="matrix(1 0 0 1 1599.0186 696.9844)" font-family="'OpenSans'" font-size="14">Facts checking and registration of hardware details</text>
|
||||
<rect x="1705.068" y="579.184" fill="none" width="228.863" height="33.316"/>
|
||||
<text transform="matrix(1 0 0 1 1705.0684 606.623)" font-family="'OpenSans'" font-size="14">Post hardware metrics</text>
|
||||
<g>
|
||||
<g>
|
||||
|
||||
<line fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" x1="1192.139" y1="321.729" x2="1404.068" y2="321.729"/>
|
||||
<g>
|
||||
<path d="M1180.068,321.729c5.68,2.107,12.727,5.703,17.095,9.512l-3.44-9.512l3.44-9.51
|
||||
C1192.795,316.027,1185.748,319.623,1180.068,321.729z"/>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
<rect x="1179.068" y="286.047" fill="none" width="228.863" height="33.316"/>
|
||||
<text transform="matrix(1 0 0 1 1295.7676 313.4868)" font-family="'OpenSans'" font-size="14">Nodes registered</text>
|
||||
<rect x="1258.858" y="748.158" fill="none" width="346.496" height="33.316"/>
|
||||
<text transform="matrix(1 0 0 1 1341.6709 758.7988)"><tspan x="0" y="0" font-family="'OpenSans-Bold'" font-size="14">Nodes are fully registered</tspan><tspan x="-38.877" y="16.799" font-family="'OpenSans-Bold'" font-size="14">wth full stack of hardware attributes</tspan></text>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
File diff suppressed because it is too large
Load Diff
|
After Width: | Height: | Size: 259 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
|
|
@ -0,0 +1,32 @@
|
|||
<?xml version="1.0" encoding="utf-8"?>
|
||||
<!-- Generator: Adobe Illustrator 16.0.4, SVG Export Plug-In . SVG Version: 6.00 Build 0) -->
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
|
||||
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
|
||||
width="644.5px" height="294px" viewBox="0 0 644.5 294" enable-background="new 0 0 644.5 294" xml:space="preserve">
|
||||
<path fill="#820A0E" d="M10.775,93.754L10.775,93.754c0-10.828,8.667-19.605,19.357-19.605h110.615
|
||||
c5.134,0,10.058,2.066,13.688,5.743s5.669,8.664,5.669,13.864v78.422c0,10.828-8.667,19.605-19.357,19.605H30.133l0,0
|
||||
c-10.691,0-19.357-8.777-19.357-19.605L10.775,93.754L10.775,93.754z"/>
|
||||
<path fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M10.775,93.754
|
||||
L10.775,93.754c0-10.828,8.667-19.605,19.357-19.605h110.615c5.134,0,10.058,2.066,13.688,5.743s5.669,8.664,5.669,13.864v78.422
|
||||
c0,10.828-8.667,19.605-19.357,19.605H30.133l0,0c-10.691,0-19.357-8.777-19.357-19.605L10.775,93.754L10.775,93.754z"/>
|
||||
<path fill-opacity="0" d="M299.077,53.848L299.077,53.848c0-21.85,17.485-39.562,39.058-39.562h255.822
|
||||
c10.358,0,20.293,4.167,27.618,11.587c7.325,7.417,11.438,17.481,11.438,27.973v158.235c0,21.85-17.485,39.562-39.058,39.562
|
||||
H338.135c-21.57,0-39.058-17.712-39.058-39.562V53.848L299.077,53.848z"/>
|
||||
<path fill="#DDDDDD" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M299.077,53.848
|
||||
L299.077,53.848c0-21.85,17.485-39.562,39.058-39.562h255.822c10.358,0,20.293,4.167,27.618,11.587
|
||||
c7.325,7.417,11.438,17.481,11.438,27.973v158.235c0,21.85-17.485,39.562-39.058,39.562H338.135
|
||||
c-21.57,0-39.058-17.712-39.058-39.562V53.848L299.077,53.848z"/>
|
||||
<path fill-opacity="0" d="M160.105,132.965h138.972"/>
|
||||
<path fill="none" stroke="#000000" stroke-width="2" stroke-linejoin="round" stroke-miterlimit="10" d="M160.105,132.965h127.253"
|
||||
/>
|
||||
<path stroke="#000000" stroke-width="2" stroke-miterlimit="10" d="M287.358,136.233l8.864-3.269l-8.864-3.268V136.233z"/>
|
||||
<path fill-opacity="0" d="M180.854,79.397h97.472v92.433h-97.472V79.397z"/>
|
||||
<rect x="17.44" y="125.359" fill="none" width="139" height="16.712"/>
|
||||
<text transform="matrix(0.9873 0 0 1 26.0718 139.2148)" fill="#FFFFFF" font-family="'OpenSans-Semibold'" font-size="18.2314">RDO-Manager</text>
|
||||
<rect x="329.94" y="125.359" fill="none" width="261" height="16.712"/>
|
||||
<text transform="matrix(0.9873 0 0 1 335.8867 139.2148)" font-family="'OpenSans-Semibold'" font-size="18.2314">Production OpenStack Cloud</text>
|
||||
<rect x="160.105" y="80.287" fill="none" width="138.972" height="106.856"/>
|
||||
<text transform="matrix(0.9873 0 0 1 202.6709 91.0645)" font-family="'OpenSans-Semibold'" font-size="14.18">Deploys</text>
|
||||
<text transform="matrix(0.9873 0 0 1 201.4199 108.0801)" font-family="'OpenSans-Semibold'" font-size="14.18">Updates</text>
|
||||
<text transform="matrix(0.9873 0 0 1 199.0068 125.0957)" font-family="'OpenSans-Semibold'" font-size="14.18">Monitors</text>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 3.0 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
File diff suppressed because it is too large
Load Diff
|
After Width: | Height: | Size: 243 KiB |
|
|
@ -255,6 +255,8 @@ After discovery has completed, we can do analysis on the benchmark data.
|
|||
However we can see that the variance of the "standalone_randread_4k_KBps"
|
||||
metric was above the threshold, so the group is marked as unstable.
|
||||
|
||||
.. _ahc_matching:
|
||||
|
||||
Exclude outliers from deployment
|
||||
--------------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,419 @@
|
|||
Architecture
|
||||
============
|
||||
RDO-Manager Architecture
|
||||
========================
|
||||
|
||||
High Availability (HA) reference architecture:
|
||||
https://github.com/beekhof/osp-ha-deploy
|
||||
This document lists the main components of RDO-Manager, and gives some
|
||||
description of how each component is used. There are links to additional sources
|
||||
of information throughout the document.
|
||||
|
||||
.. contents::
|
||||
:depth: 3
|
||||
:backlinks: none
|
||||
|
||||
|
||||
Architecture Overview
|
||||
---------------------
|
||||
|
||||
RDO-Manager is a community developed approach and set of tools for deploying,
|
||||
and managing OpenStack cloud which is built upon the `TripleO
|
||||
<https://wiki.openstack.org/wiki/TripleO>`_ project and its philosophy is
|
||||
inspired by `SpinalStack <http://spinal-stack.readthedocs.org/en/latest/>`_.
|
||||
|
||||
|
||||
TripleO
|
||||
^^^^^^^
|
||||
|
||||
TripleO is the friendly name for “OpenStack on OpenStack”. It is an official
|
||||
OpenStack program with the goal of allowing you to deploy and manage a
|
||||
production cloud onto bare metal hardware using a subset of existing OpenStack
|
||||
components.
|
||||
|
||||
.. image:: ../_images/overview.png
|
||||
|
||||
With TripleO, you start by creating an “undercloud” (a deployment cloud)
|
||||
that will contain the necessary OpenStack components to deploy and manage an
|
||||
“overcloud” (a workload cloud). The overcloud is the deployed solution
|
||||
and can represent a cloud for any purpose (e.g. production, staging, test, etc).
|
||||
The operator can choose any OpenStack components they want for the overcloud.
|
||||
|
||||
.. image:: ../_images/logical_view.png
|
||||
|
||||
TripleO leverages several existing core components of OpenStack including Nova,
|
||||
Neutron, Heat, Glance and Ceilometer to deploy OpenStack on hardware. Nova and
|
||||
Ironic are used in the undercloud to manage bare metal instances that comprise
|
||||
the infrastructure for the overcloud. Neutron is utilized to provide a
|
||||
networking environment in which to deploy the overcloud, machine images are
|
||||
stored in Glance and Ceilometer collects metrics about your overcloud.
|
||||
|
||||
The following diagram illustrates a physical view of how the undercloud may be
|
||||
hosted on one physical server and the overcloud distributed across many physical
|
||||
servers.
|
||||
|
||||
.. image:: ../_images/physical_view.png
|
||||
|
||||
|
||||
SpinalStack's Inspiration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Some key aspects of SpinalStack workflow have been incorporated into
|
||||
RDO-Manager, providing options to perform introspection, benchmarking and role
|
||||
matching of your hardware prior to deploying OpenStack.
|
||||
|
||||
Hardware introspection features enable you to collect data about the properties
|
||||
of your hardware prior to deployment, such that specific classes of hardware may
|
||||
be matched to specific roles (e.g a special hardware configuration for Compute,
|
||||
or Storage roles). There is also the option to enable performance benchmarking
|
||||
during this phase, such that outliers which do not match the expected
|
||||
performance profile may be excluded from the deployment.
|
||||
|
||||
RDO-Manager also configures servers in a similar way to SpinalStack, using
|
||||
stable community puppet implementations, applied in a series of passes, such
|
||||
that granular control and validation of the deployment is possible
|
||||
|
||||
|
||||
Benefits
|
||||
--------
|
||||
|
||||
Using RDO-Manager’s combination of OpenStack components, and their APIs, as the
|
||||
infrastructure to deploy and operate OpenStack itself delivers several benefits:
|
||||
|
||||
* RDO-Manager’s APIs are the OpenStack APIs. They’re well maintained, well
|
||||
documented, and come with client libraries and command line tools. Users who
|
||||
invest time in learning about RDO-Manager’s APIs are also learning about
|
||||
OpenStack itself, and users who are already familiar with OpenStack will find
|
||||
a great deal in RDO-Manager that they already understand.
|
||||
* Using the OpenStack components allows more rapid feature development of
|
||||
RDO-Manager than might otherwise be the case; RDO-Manager automatically
|
||||
inherits all the new features which are added to Glance, Heat etc., even when
|
||||
the developer of the new feature didn’t explicitly have TripleO and
|
||||
RDO-Manager in mind.
|
||||
* The same applies to bug fixes and security updates. When OpenStack developers
|
||||
fix bugs in the common components, those fixes are inherited by RDO-Manager.
|
||||
* Users’ can invest time in integrating their own scripts and utilities with
|
||||
RDO-Manager’s APIs with some confidence. Those APIs are cooperatively
|
||||
maintained and developed by the OpenStack community. They’re not at risk of
|
||||
being suddenly changed or retired by a single controlling vendor.
|
||||
* For developers, tight integration with the openstack APIs provides a solid
|
||||
architecture, which has gone through extensive community review.
|
||||
|
||||
It should be noted that not everything in RDO-Manager is a reused OpenStack
|
||||
element. The Tuskar API, for example (which lets users design the workload cloud
|
||||
that they want to deploy), is found in RDO-Manager but not, so far at least, in
|
||||
a typical Openstack instance. The Tuskar API is described in more detail below.
|
||||
|
||||
|
||||
|
||||
Deployment Workflow Overview
|
||||
----------------------------
|
||||
|
||||
#. Environment Preparation
|
||||
|
||||
* Prepare your environemnt (baremetal or virtual)
|
||||
* Install undercloud
|
||||
|
||||
|
||||
#. Undercloud Data Preparation
|
||||
|
||||
* Create images to establish the overcloud
|
||||
* Register hardware nodes with undercloud
|
||||
* Introspect hardware
|
||||
* Create flavors (node profiles)
|
||||
|
||||
|
||||
#. Deployment Planning
|
||||
|
||||
* Configure overcloud roles
|
||||
|
||||
* Assign flavor (node profile to match desired hardware specs)
|
||||
* Assign image (provisioning image)
|
||||
* Size the role (how many instances to deploy)
|
||||
|
||||
* Configure service parameters
|
||||
* Create a Heat template describing the overcloud (auto-generated from above)
|
||||
|
||||
|
||||
#. Deployment
|
||||
|
||||
* Use Heat to deploy your template
|
||||
* Heat will use Nova to identify and reserve the appropriate nodes
|
||||
* Nova will use Ironic to startup nodes and install the correct images
|
||||
|
||||
|
||||
#. Per-node Setup
|
||||
|
||||
* When each node of the overcloud starts it will gather its configuration
|
||||
metadata from Heat Template configuration files
|
||||
* Hiera files are distributed across all nodes and Heat applies puppet
|
||||
manifests to configure the services on the nodes
|
||||
* Puppet runs in multiple steps, so that after each step there can be test
|
||||
triggered to check progress of the deployment and allow easier debugging.
|
||||
|
||||
|
||||
#. Overcloud Initialization
|
||||
|
||||
* Services on nodes of the overcloud are registered with Keystone
|
||||
|
||||
|
||||
Deployment Workflow Detail
|
||||
--------------------------
|
||||
|
||||
Environment Preparation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In the first place, you need to check that your environment is ready.
|
||||
RDO-Manager can deploy OpenStack into baremetal as well as virtual environments.
|
||||
You need to make sure that your environment satisfies minimum requirements for
|
||||
given environemnt type and that networking is correctly set up.
|
||||
|
||||
Next step is to install the undercloud. We install undercloud using `Instack
|
||||
<https://github.com/rdo-management/instack-undercloud>`_'s script and it calls
|
||||
puppet scripts in the background. Upstream TripleO developers also use the
|
||||
developer-based steps known as `devtest <http://docs.openstack.org/developer/
|
||||
tripleo-incubator/devtest.html>`_.
|
||||
|
||||
|
||||
Undercloud Data Preparation
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Images
|
||||
""""""
|
||||
|
||||
Before deploying the overcloud, you must first download or build images which
|
||||
will be installed on each of the nodes of the overcloud. TripleO uses
|
||||
`diskimage-builder <https://github.com/openstack/diskimage-builder>`_ for
|
||||
building these so called "Golden Images". The diskimage-builder tool takes a
|
||||
base image e.g. `CentOS 7 <http://cloud.centos.org/centos/7/images/
|
||||
CentOS-7-x86_64-GenericCloud.qcow2>`_ and then layers additional software via
|
||||
configuration scripts (called elements) on top of that. The final result is a
|
||||
qcow2 formatted image with software installed but not configured.
|
||||
|
||||
While the diskimage-builder repository provides operating-system specific
|
||||
elements, ones specific to OpenStack, e.g. nova-api, are found in
|
||||
`tripleo-image-elements <https://github.com/openstack/tripleo-image-elements>`_.
|
||||
You can add different elements to an image to provide specific applications and
|
||||
services. Once all the images required to deploy the overcloud are built, they
|
||||
are stored in Glance running on the undercloud.
|
||||
|
||||
|
||||
Nodes
|
||||
"""""
|
||||
|
||||
Deploying the overcloud requires suitable hardware. The first task is to
|
||||
register the available hardware with Ironic, OpenStack’s equivalent of a
|
||||
hypervisor for managing baremetal servers. User can define the hardware
|
||||
attributes (such as number of CPUs, RAM, disk) manually or he can leave the
|
||||
fields out and run introspection of the nodes afterwards.
|
||||
|
||||
The sequence of events is pictured below:
|
||||
|
||||
.. image:: ../_images/discovery_diagram.png
|
||||
|
||||
* The user, via the GUI, the command-line tools, or through direct API calls,
|
||||
registers the power management credentials for a node with Ironic.
|
||||
* The user then instructs Ironic to reboot the node.
|
||||
* Because the node is new, and not already fully registered, there are no
|
||||
specific PXE-boot instructions for it. In that case, the default action is to
|
||||
boot into a discovery ramdisk
|
||||
* The discovery ramdisk probes the hardware on the node and gathers facts,
|
||||
including the number of CPU cores, the local disk size and the amount of RAM.
|
||||
* The ramdisk posts the facts to the discoverd API.
|
||||
* All facts are passed and stored in the Ironic databse.
|
||||
* There can be performed advanced role matching via the ''ahc-match'' tool,
|
||||
which simply adds an additional role categorization to Ironic based on
|
||||
discovered node facts and specified conditions.
|
||||
|
||||
|
||||
Flavors
|
||||
"""""""
|
||||
|
||||
When users are creating virtual machines (VMs) in an OpenStack cloud, the flavor
|
||||
that they choose specifies the capacity of the VM which should be created. The
|
||||
flavor defines the CPU count, the amount of RAM, the amount of disk space etc.
|
||||
As long as the cloud has enough capacity to grant the user’s wish, and the user
|
||||
hasn’t reached their quota limit, the flavor acts as a set of instructions on
|
||||
exactly what kind of VM to create on the user’s behalf.
|
||||
|
||||
In the undercloud, where the machines are usually physical rather than virtual
|
||||
(or, at least, pre-existing, rather than created on demand), flavors have a
|
||||
slightly different effect. Essentially, they act as a constraint. Of all of the
|
||||
discovered hardware, only nodes which match a specified flavor are suitable for
|
||||
a particular role. This can be used to ensure that the large machines with a
|
||||
great deal of RAM and CPU capacity are used to run Nova in the overcloud, and
|
||||
the smaller machines run less demanding services, such as Keystone.
|
||||
|
||||
The version of TripleO included in RDO-Manager is capable of handling flavors in
|
||||
two different modes. The simpler PoC (Proof of Concept) mode is intended to
|
||||
enable new users to experiment, without worrying about matching hardware
|
||||
profiles. In the mode, there’s one single, global flavor, and any hardware can
|
||||
match it. That effectively removes flavor matching. Users can use whatever
|
||||
hardware they wish.
|
||||
|
||||
For the second mode, named Scale because it is suited to larger scale overcloud
|
||||
deployments, flavor matching is in full effect. A node will only be considered
|
||||
suitable for a given role if the role is associated with a flavor which matches
|
||||
the capacity of the node. Nodes without a matching flavor are effectively
|
||||
unusable.
|
||||
|
||||
This second mode allows users to ensure that their different hardware types end
|
||||
up running their intended role, though requires manual configuration of the role
|
||||
definitions and role matching via the ahc-match tool (:ref:`ahc_matching`).
|
||||
|
||||
|
||||
|
||||
Deployment Planning
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Whole part of planning your deployment is based on concept of **overcloud
|
||||
roles**.
|
||||
|
||||
Roles are stored in the Tuskar DB, and are used through interaction with the
|
||||
Tuskar API. A role brings together following things:
|
||||
|
||||
* An image; the software to be installed on a node
|
||||
* A flavor; the size of node suited to the role
|
||||
* A size; number of instances which should be deployed having given role
|
||||
* A set of heat templates; instructions on how to configure the node for its
|
||||
task
|
||||
|
||||
|
||||
In the case of the “Compute” role:
|
||||
|
||||
* the image must contain all the required software to boot an OS and then run
|
||||
the KVM hypervisor and the Nova compute service
|
||||
* the flavor (at least for a deployment which isn’t a simple proof of concept),
|
||||
should specify that the machine has enough CPU capacity and RAM to host
|
||||
several VMs concurrently
|
||||
* the Heat templates will take care of ensuring that the Nova service is
|
||||
correctly configured on each node when it first boots.
|
||||
|
||||
|
||||
Currently, the roles in RDO-Manager are very prescriptive, and in particular
|
||||
individual services cannot easily be scaled independently of the Controller role
|
||||
(other than storage nodes). More flexibility in this regard is planned in a
|
||||
future release.
|
||||
|
||||
Customizable things during deployment planning are:
|
||||
* Number of nodes for each role
|
||||
* Service parameters configuration
|
||||
* Network configuration (NIC configuration options, isolated vs. single overlay)
|
||||
* Ceph rbd backend options and defaults
|
||||
* Ways to pass in extra configuration, e.g site-specific customzations
|
||||
|
||||
|
||||
Deployment
|
||||
^^^^^^^^^^
|
||||
|
||||
Deployment to physical servers happens through a collaboration of Tuskar, Heat,
|
||||
Nova, Neutron, Glance and Ironic.
|
||||
|
||||
To deploy the overcloud Tuskar needs gather all plan information it keeps and
|
||||
build a Heat templates which describe desired overcloud.
|
||||
|
||||
This template is served to to Heat which will orchestrate the whole deployment
|
||||
and it will create a stack. Stak is Heat’s own term for the applications that it
|
||||
creates. The overcloud, in Heat terms, is a particularly complex instance of a
|
||||
stack.
|
||||
|
||||
In order to the stack to be deployed, Heat makes successive calls to Nova,
|
||||
OpenStack’s compute service controller. Nova depends upon Ironic, which, as
|
||||
described above has acquired an inventory of discovered hardware by this stage
|
||||
in the process.
|
||||
|
||||
At this point, Nova flavors may act as a constraint, influencing the range of
|
||||
machines which may be picked for deployment by the Nova scheduler. For each
|
||||
request to deploy a new node with a specific role, Nova filters the of available
|
||||
nodes, ensuring that the selected nodes meets the hardware requirements.
|
||||
|
||||
Once the target node has been selected, Ironic does the actual provisioning of
|
||||
the node, Ironic retrieves the OS image associated with the role from Glance,
|
||||
causes the node to boot a deployment ramdisk and then, in the typical case,
|
||||
exports the node’s local disk over iSCSI so that the disk can be partitioned and
|
||||
the have the OS image written onto it by the Ironic Conductor.
|
||||
|
||||
See Ironic’s `Understanding Baremetal Deployment <http://docs.openstack.org/
|
||||
developer/ironic/deploy/user-guide.html#understanding-bare-metal-deployment>`_
|
||||
for further details.
|
||||
|
||||
|
||||
Per-node Setup
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
TBD - Puppet
|
||||
|
||||
|
||||
Overcloud Initialization
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
After the overcloud has been deployed, the initialization of OpenStack services
|
||||
(e.g Keystone, Neutron, etc) needs to occur. That is accomplished today by
|
||||
scripts in the `tripleo-incubator <https://github.com/openstack/
|
||||
tripleo-incubator>`_ source repository and it uses bits from `os-cloud-config
|
||||
<https://github.com/openstack/os-cloud-config>`_ which contains common code,
|
||||
the seed initialisation logic, and the post heat completion initial
|
||||
configuration of a cloud. There are three primary steps to completing the
|
||||
initialization:
|
||||
|
||||
* Initializing Identity Services (Keystone)
|
||||
* Registering service endpoints (e.g. Glance, Nova)
|
||||
* Specify a block of IP addresses for overcloud instances (Neutron)
|
||||
|
||||
The first step initializes Keystone for use with normal authentication by
|
||||
creating the admin and service tenants, the admin and Member roles, the admin
|
||||
user, configure certificates and finally registers the initial identity
|
||||
endpoint. The next step registers image, orchestration, network and compute
|
||||
services running on the default ports on the controlplane node. Finally, Neutron
|
||||
is given a starting IP address, ending IP address, and a CIDR notation to
|
||||
represent the subnet for the block of floating IP addresses that will be used
|
||||
within the overcloud.
|
||||
|
||||
|
||||
|
||||
High Availability (HA)
|
||||
----------------------
|
||||
|
||||
RDO-Manager will use Pacemaker to achieve high-availability.
|
||||
|
||||
Reference architecture document: https://github.com/beekhof/osp-ha-deploy
|
||||
|
||||
.. note:: **Current HA solution is being developed by our community.**
|
||||
|
||||
|
||||
|
||||
Managing the Deployment
|
||||
-----------------------
|
||||
|
||||
After the overcloud deployment is completed, it will be possible to monitor,
|
||||
scale it out or perform basic maintenance operations via GUI or CLI.
|
||||
|
||||
|
||||
Monitoring the Overcloud
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When the overcloud is deployed, Ceilometer can be configured to track a set of
|
||||
OS metrics for each node (system load, CPU utiization, swap usage etc.) These
|
||||
metrics are graphed in the GUI, both for individual nodes, and for groups
|
||||
of nodes, such as the collection of nodes which are all delivering a particular
|
||||
role.
|
||||
|
||||
Additionally, Ironic exports IPMI metrics for nodes, which can also be stored in
|
||||
Ceilometer. This enables checks on hardware state such as fan operation/failure
|
||||
and internal chassis temperatures.
|
||||
|
||||
The metrics which Ceilometer gathers can be queried for Ceilometer's REST API,
|
||||
or by using the command line client.
|
||||
|
||||
.. Note::
|
||||
There are plans to add more operational tooling to the future release.
|
||||
|
||||
|
||||
Scaling-out the Overcloud
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The process of scaling out the overcloud by adding new nodes involves these
|
||||
stages:
|
||||
|
||||
* Making sure you have enough nodes to deploy on (or register new nodes as
|
||||
described in the "Undercloud Data Preparation" section above).
|
||||
* Updating the plan managed by Tuskar, as described in the “Deployment Planning"
|
||||
section above.
|
||||
* Calling Heat to update the stack which will apply the set of changes to the
|
||||
overcloud.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,7 @@ RDO-Manager Components
|
|||
|
||||
.. contents::
|
||||
:depth: 2
|
||||
:backlinks: none
|
||||
|
||||
This section contains a list of components that RDO-Manager uses. The components
|
||||
are organized in categories, and include a basic description, useful links, and
|
||||
|
|
|
|||
|
|
@ -6,25 +6,6 @@ RDO-Manager is an OpenStack Deployment & Management tool for RDO. It is based on
|
|||
philosophy is inspired by `SpinalStack <http://spinal-stack.readthedocs.org/en/
|
||||
latest/>`_.
|
||||
|
||||
The tooling allows you to deploy a management node ("undercloud") which contains
|
||||
the services required to then deploy your OpenStack environment ("overcloud")
|
||||
|
||||
.. image:: ../_images/ArchitectureOverview.svg
|
||||
|
||||
RDO manager provides semi-automated configuration of your undercloud
|
||||
environment, after which it is possible to deploy an overcloud containing your
|
||||
desired number of overcloud resource nodes (using either UI or CLI interfaces).
|
||||
|
||||
Overcloud resource nodes may be independently scaled, and support exists for the following roles:
|
||||
|
||||
Controller
|
||||
The Controller nodes contain the OpenStack API services and associated dependencies.
|
||||
|
||||
Compute
|
||||
The Compute nodes contain the Nova compute (hypervisor) components.
|
||||
|
||||
Storage
|
||||
Optional Storage roles exist which allow you to scale Ceph, Swift or LVM based Cinder storage independently of the controller.
|
||||
|
||||
Useful links:
|
||||
|
||||
|
|
@ -32,9 +13,29 @@ Useful links:
|
|||
|
||||
* `RDO-Manager Repositories <http://github.com/rdo-management>`_
|
||||
|
||||
* `TripleO Documentation <http://docs.openstack.org/developer/tripleo-incubator/README.html>`_.
|
||||
* `TripleO Documentation <http://docs.openstack.org/developer/tripleo-incubator/README.html>`_
|
||||
|
||||
* :doc:`components`
|
||||
|
|
||||
|
||||
**Architecture**
|
||||
|
||||
With RDO-Manager, you start by creating an **undercloud** (an actual operator
|
||||
facing deployment cloud) that will contain the necessary OpenStack components to
|
||||
deploy and manage an **overcloud** (an actual tenant facing workload cloud). The
|
||||
overcloud is the deployed solution and can represent a cloud for any purpose
|
||||
(e.g. production, staging, test, etc). The operator can choose any of available
|
||||
Overcloud Roles (OpenStack components) they want to deploy to his environment.
|
||||
|
||||
Go to :doc:`architecture` to learn more.
|
||||
|
||||
|
|
||||
|
||||
**Components**
|
||||
|
||||
RDO-Manager is composed of set of official OpenStack components accompanied by
|
||||
few other open sourced plugins which are increasing RDO-Manager capabilities.
|
||||
|
||||
Go to :doc:`components` to learn more.
|
||||
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
Loading…
Reference in New Issue