Merge "Adding information on storage IP connections"
This commit is contained in:
commit
184ea557ac
@ -74,11 +74,18 @@
|
|||||||
network.</para>
|
network.</para>
|
||||||
<para>A new empty disk, labeled <literal>vdb</literal> is also created. This is an empty
|
<para>A new empty disk, labeled <literal>vdb</literal> is also created. This is an empty
|
||||||
ephemeral disk, which is destroyed when you delete the instance.</para>
|
ephemeral disk, which is destroyed when you delete the instance.</para>
|
||||||
<para>The compute node is attached to the <systemitem class="service">cinder-volume</systemitem>
|
<para>The compute node connects to the attached
|
||||||
using iSCSI, and maps to the third disk, <literal>vdc</literal>. The vCPU and memory
|
<systemitem class="service">cinder-volume</systemitem> using
|
||||||
resources are provisioned and the instance is booted from <literal>vda</literal>. The
|
ISCSI. The <systemitem class="service">cinder-volume</systemitem>
|
||||||
instance runs and changes data on the disks as indicated in red in the diagram.
|
is mapped to the third disk, <literal>vdc</literal>. After the
|
||||||
<!--This isn't very accessible, need to consider rewording to explain more fully. LKB --></para>
|
compute node provisions the vCPU and memory resources, the
|
||||||
|
instance boots up from root volume <literal>vda</literal>.
|
||||||
|
The instance runs, and changes data on the disks (highlighted in
|
||||||
|
red on the diagram). If the volume store is located
|
||||||
|
on a separate network, the <literal>my_block_storage_ip</literal>
|
||||||
|
option specified in the storage node configuration file directs
|
||||||
|
image traffic toward the compute node.
|
||||||
|
</para>
|
||||||
<note>
|
<note>
|
||||||
<para>Some details in this example scenario might be different in your environment.
|
<para>Some details in this example scenario might be different in your environment.
|
||||||
For example, you might use a different type of back-end storage or different network
|
For example, you might use a different type of back-end storage or different network
|
||||||
|
@ -25,6 +25,13 @@
|
|||||||
connection. The Image Service streams the image from the back end to the
|
connection. The Image Service streams the image from the back end to the
|
||||||
compute node.
|
compute node.
|
||||||
</para>
|
</para>
|
||||||
|
<para>
|
||||||
|
It is possible to set up the Object Storage node on a separate network,
|
||||||
|
and still allow image traffic to flow between the Compute and Object
|
||||||
|
Storage nodes. Configure the <literal>my_block_storage_ip</literal>
|
||||||
|
option in the storage node configuration to allow block storage traffic
|
||||||
|
to reach the Compute node.
|
||||||
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Certain back ends support a more direct method, where on request
|
Certain back ends support a more direct method, where on request
|
||||||
the Image Service will return a URL that can be used to
|
the Image Service will return a URL that can be used to
|
||||||
|
Loading…
Reference in New Issue
Block a user