Open Stack

Hi Alan,
Can you please check if the environment file attached is in correct format
and how it should be?
Also should i remove the old netapp environment file and use the new custom
environment file created (attached).

With regards,
Swogat Pradhan

On Wed, May 31, 2023 at 10:46 PM Swogat Pradhan <swogatpradhan22 at gmail.com>
wrote:

> Hi Alan,
> Thanks for your clarification, the way you suggested will solve my issue.
> But i already have a netapp backend in my central site and to add another
> backend should i follow this documentation:
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/17.0/html/custom_block_storage_back_end_deployment_guide/ref_configuration-sample-environment-file_custom-cinder-back-end
>
> And should i remove the old netapp environment file and use the new custom
> environment file created using the above mentioned guide??
>
> I already have a prod workload in the currently deployed netapp and I do
> not want to cause any issues in that netapp storage.
>
>
> With regards,
> Swogat Pradhan
>
> On Tue, May 30, 2023 at 8:43 PM Alan Bishop <abishop at redhat.com> wrote:
>
>>
>>
>> On Thu, May 25, 2023 at 9:39 PM Swogat Pradhan <swogatpradhan22 at gmail.com>
>> wrote:
>>
>>> Hi Alan,
>>> My netapp storage is located in edge site itself.
>>> As the networks are routable my central site is able to reach the netapp
>>> storage ip address (ping response is 30ms-40ms).
>>> Let's say i included the netapp storage yaml in central site deployment
>>> script (which is not recommended) and i am able to create the volumes as it
>>> is reachable from controller nodes.
>>> Will i be able to mount those volumes in edge site VM's?? And if i am
>>> able to do so, then how will the data flow?? When storing something in the
>>> netapp volume will the data flow through the central site controller and
>>> get stored in the storage space?
>>>
>>
>> A cinder-volume service running in the central site's controplane will be
>> able to work with a netapp backend that's physically located at an edge
>> site. The good news is the c-vol service will be HA because it will be
>> controlled by pacemaker running on the controllers.
>>
>> In order for VMs at the edge site to access volumes on the netapp, you'll
>> need to set the CinderNetappAvailabilityZone [1] to the edge site's AZ.
>>
>> [1]
>> https://opendev.org/openstack/tripleo-heat-templates/src/branch/stable/wallaby/deployment/cinder/cinder-backend-netapp-puppet.yaml#L43
>>
>> To attach a netapp volume, nova-compute at the edge will interact with
>> cinder-volume in the controlplane, and cinder-volume will in turn interact
>> with the netapp. This will happen over central <=> edge network
>> connections. Eventually, nova will directly connect to the netapp, so all
>> traffic from the VM to the netapp will occur within the edge site. Data
>> will not flow through the cinder-volume service, but there are restrictions
>> and limitations:
>> - Only that one edge site can access the netapp backend
>> - If the central <=> edge network connection then you won't be able to
>> attach or detach a netapp volume (but active connections will continue to
>> work)
>>
>> Of course, there are operations where cinder services are in the data
>> path (e.g. creating a volume from an image), but not when a VM is accessing
>> a volume.
>>
>> Alan
>>
>>
>>> With regards,
>>> Swogat Pradhan
>>>
>>> On Fri, 26 May 2023, 10:03 am Alan Bishop, <abishop at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 25, 2023 at 12:09 AM Swogat Pradhan <
>>>> swogatpradhan22 at gmail.com> wrote:
>>>>
>>>>> Hi Alan,
>>>>> So, can I include the cinder-netapp-storage.yaml file in the central
>>>>> site and then use the new backend to add storage to edge VM's?
>>>>>
>>>>
>>>> Where is the NetApp physically located? Tripleo's DCN architecture
>>>> assumes the storage is physically located at the same site where the
>>>> cinder-volume service will be deployed. If you include the
>>>> cinder-netapp-storage.yaml environment file in the central site's
>>>> controlplane, then VMs at the edge site will encounter the problems I
>>>> outlined earlier (network latency, no ability to do cross-AZ attachments).
>>>>
>>>>
>>>>> I believe it is not possible right?? as the cinder volume in the edge
>>>>> won't have the config for the netapp.
>>>>>
>>>>
>>>> The cinder-volume services at an edge site are meant to manage storage
>>>> devices at that site. If the NetApp is at the edge site, ideally you'd
>>>> include some variation of the cinder-netapp-storage.yaml environment file
>>>> in the edge site's deployment. However, then you're faced with the fact
>>>> that the NetApp driver doesn't support A/A, which is required for c-vol
>>>> services running at edge sites (In case you're not familiar with these
>>>> details, tripleo runs all cinder-volume services in active/passive mode
>>>> under pacemaker on controllers in the controlplane. Thus, only a single
>>>> instance runs at any time, and pacemaker provides HA by moving the service
>>>> to another controller if the first one goes down. However, pacemaker is not
>>>> available at edge sites, and so to get HA, multiple instances of the
>>>> cinder-volume service run simultaneously on 3 nodes (A/A), using etcd as a
>>>> Distributed Lock Manager (DLM) to coordinate things. But drivers must
>>>> specifically support running A/A, and the NetApp driver does NOT.)
>>>>
>>>> Alan
>>>>
>>>>
>>>>> With regards,
>>>>> Swogat Pradhan
>>>>>
>>>>> On Thu, May 25, 2023 at 2:17 AM Alan Bishop <abishop at redhat.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, May 24, 2023 at 3:15 AM Swogat Pradhan <
>>>>>> swogatpradhan22 at gmail.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>> I have a DCN setup and there is a requirement to use a netapp
>>>>>>> storage device in one of the edge sites.
>>>>>>> Can someone please confirm if it is possible?
>>>>>>>
>>>>>>
>>>>>> I see from prior email to this list that you're using tripleo, so
>>>>>> I'll respond with that in mind.
>>>>>>
>>>>>> There are many factors that come into play, but I suspect the short
>>>>>> answer to your question is no.
>>>>>>
>>>>>> Tripleo's DCN architecture requires the cinder-volume service running
>>>>>> at edge sites to run in active-active
>>>>>> mode, where there are separate instances running on three nodes in to
>>>>>> for the service to be highly
>>>>>> available (HA).The problem is that only a small number of cinder
>>>>>> drivers support running A/A, and NetApp's
>>>>>> drivers do not support A/A.
>>>>>>
>>>>>> It's conceivable you could create a custom tripleo role that deploys
>>>>>> just a single node running cinder-volume
>>>>>> with a NetApp backend, but it wouldn't be HA.
>>>>>>
>>>>>> It's also conceivable you could locate the NetApp system in the
>>>>>> central site's controlplane, but there are
>>>>>> extremely difficult constraints you'd need to overcome:
>>>>>> - Network latency between the central and edge sites would mean the
>>>>>> disk performance would be bad.
>>>>>> - You'd be limited to using iSCSI (FC wouldn't work)
>>>>>> - Tripleo disables cross-AZ attachments, so the only way for an edge
>>>>>> site to access a NetApp volume
>>>>>> would be to configure the cinder-volume service running in the
>>>>>> controlplane with a backend availability
>>>>>> zone set to the edge site's AZ. You mentioned the NetApp is needed
>>>>>> "in one of the edge sites," but in
>>>>>> reality the NetApp would be available in one, AND ONLY ONE edge site,
>>>>>> and it would also not be available
>>>>>> to any instances running in the central site.
>>>>>>
>>>>>> Alan
>>>>>>
>>>>>>
>>>>>>> And if so then should i add the parameters in the edge deployment
>>>>>>> script or the central deployment script.
>>>>>>> Any suggestions?
>>>>>>>
>>>>>>> With regards,
>>>>>>> Swogat Pradhan
>>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230531/666d8f9c/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cinder-netapp-custom-env - Copy.yml
Type: application/octet-stream
Size: 1984 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230531/666d8f9c/attachment.obj>