<div dir="ltr">I'm not sure to be getting your idea here, how would you do it with NFS? Who would be the NFS exporting server? <div><br></div><div>As you can see I don't have too much experience with cinder at all, we've been using the LVM driver since we installed it a year and a half ago.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-16 16:09 GMT-03:00 Abel Lopez <span dir="ltr"><<a href="mailto:alopgeek@gmail.com" target="_blank">alopgeek@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Some of your concerns might be addressed by switching to NFS as the protocol.<div>You’re already exporting large luns to your cinder-volume servers, using NFS they would both be writeable by both nodes, so if one goes down, there is no need to “swing luns over”</div><div><div class="h5"><div><br><div><div>On Sep 16, 2014, at 11:27 AM, Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com" target="_blank">jjpavlik@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Hi Abel, I thought about trying it, but We had MANY performance problems with the EMC because of running too many LUNs that's way we`d like to avoid that scenario. It might seem the best solution but We don't want to go that way again. </div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-16 15:20 GMT-03:00 Abel Lopez <span dir="ltr"><<a href="mailto:alopgeek@gmail.com" target="_blank">alopgeek@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Have you tried using the native Emc drivers? That way cinder only acts as a broker between your instances and the storage back end, and you don't need to worry about your cinder-volume service being HA. (As much)<div><div><span></span><br><br>On Tuesday, September 16, 2014, Juan José Pavlik Salles <<a href="mailto:jjpavlik@gmail.com" target="_blank">jjpavlik@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi guys, I'm trying to put some HA on our cinder service, we have the next scenario:<div><br></div><div>-Real backends: EMC clarion (SATA drives) and HP Storevirtual P4000 (SAS drives), this two backends export 2 big LUNs to our (one and only right now) cinder server.</div><div>-Once these big LUNs are imported in the cinder server, two different VG are created for two different cinder LVM drivers (cinder-volumes-1 and cinder-volumes-2). This way I have two different storage resources to give to my tenants.</div><div><br></div><div>What I want is to deploy a second cinder server to act as failover of the first one. Both servers are identical. So far I'm running a few tests with isolated VMs.</div><div><br></div><div>-I installed corosync+pacemaker in 2 VMs, added a Virtual IP.</div><div>-Imported in the VMs a LUN with iSCSI created a VG</div><div>-Exported a LV with tgt. More or less the same scenario we have on production. </div><div><br></div><div>If one of the VMs die the second one picks the virtual IP throughtout tgt is exporting the LUN and the iSCSI session doesn't die, here you can see part of the logs where the LUN is being imported:</div><div><br></div><div><div>Sep 16 14:29:50 borrar-nfs kernel: [86630.416160]  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4316547395, last ping 4316548646, now 4316549900</div><div>Sep 16 14:29:50 borrar-nfs kernel: [86630.418938]  connection1:0: detected conn error (1011)</div><div>Sep 16 14:29:51 borrar-nfs iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)</div><div>Sep 16 14:29:53 borrar-nfs iscsid: connection1:0 is operational after recovery (1 attempts)</div></div><div><br></div><div>This test was really simple, just one 1GB LUN but it worked ok, even when the failover was tested during a writing operation.</div><div><br></div><div>So it seems to be a good-so-far-solution, but there are a few things that worries me a bit:<br></div><div><br></div><div>-Timeouts? How much time do I have to detect the problem and move the IP to the new node before the iscsi connections die. I think I could play a little bit with timeo.noop_out_timeout in iscsid.conf</div><div>-What if there was a write operation going on while a node failed, what if this operation never reached the real backends, could I come across some inconsistencies in the volume FS? Any recommendations?</div><div>-If I create a volume in cinder, the proper target file is created in /var/lib/cinder/volumes/volue-* but, I need the file to be created in both cinder nodes in case one of them fail. What would be a proper solution for this? shared storage for the directory? SVN?</div><div>-Both servers should be running tgt at the same time or maybe I should start tgt on the failover server once the virtual IP is changed?</div><div><br></div><div>Any comments or suggestions will be more than appreciated. Thanks!</div><div><div><br></div>-- <br><div dir="ltr">Pavlik Salles Juan José<div>Blog - <a href="http://viviendolared.blogspot.com/" target="_blank">http://viviendolared.blogspot.com</a></div></div>
</div></div>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Pavlik Salles Juan José<div>Blog - <a href="http://viviendolared.blogspot.com/" target="_blank">http://viviendolared.blogspot.com</a></div></div>
</div>
</blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Pavlik Salles Juan José<div>Blog - <a href="http://viviendolared.blogspot.com" target="_blank">http://viviendolared.blogspot.com</a></div></div>
</div>