Yes, you can export your large luns from the EMC via NFS to both your cinder-volume servers. That way they both have access to everything. Of course, you’d need to ensure that cinder user has the same UID on both nodes, and both nodes need root permissions on the shares. Check out the docs http://docs.openstack.org/admin-guide-cloud/content/nfs_backend.html
On Sep 16, 2014, at 12:23 PM, Juan José Pavlik Salles <jjpav...@gmail.com> wrote: > I'm not sure to be getting your idea here, how would you do it with NFS? Who > would be the NFS exporting server? > > 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. > > 2014-09-16 16:09 GMT-03:00 Abel Lopez <alopg...@gmail.com>: > Some of your concerns might be addressed by switching to NFS as the protocol. > 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” > > On Sep 16, 2014, at 11:27 AM, Juan José Pavlik Salles <jjpav...@gmail.com> > wrote: > >> 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. >> >> 2014-09-16 15:20 GMT-03:00 Abel Lopez <alopg...@gmail.com>: >> 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) >> >> >> On Tuesday, September 16, 2014, Juan José Pavlik Salles <jjpav...@gmail.com> >> wrote: >> Hi guys, I'm trying to put some HA on our cinder service, we have the next >> scenario: >> >> -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. >> -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. >> >> 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. >> >> -I installed corosync+pacemaker in 2 VMs, added a Virtual IP. >> -Imported in the VMs a LUN with iSCSI created a VG >> -Exported a LV with tgt. More or less the same scenario we have on >> production. >> >> 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: >> >> 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 >> Sep 16 14:29:50 borrar-nfs kernel: [86630.418938] connection1:0: detected >> conn error (1011) >> Sep 16 14:29:51 borrar-nfs iscsid: Kernel reported iSCSI connection 1:0 >> error (1011) state (3) >> Sep 16 14:29:53 borrar-nfs iscsid: connection1:0 is operational after >> recovery (1 attempts) >> >> This test was really simple, just one 1GB LUN but it worked ok, even when >> the failover was tested during a writing operation. >> >> So it seems to be a good-so-far-solution, but there are a few things that >> worries me a bit: >> >> -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 >> -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? >> -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? >> -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? >> >> Any comments or suggestions will be more than appreciated. Thanks! >> >> -- >> Pavlik Salles Juan José >> Blog - http://viviendolared.blogspot.com >> >> >> >> -- >> Pavlik Salles Juan José >> Blog - http://viviendolared.blogspot.com > > > > > -- > Pavlik Salles Juan José > Blog - http://viviendolared.blogspot.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
