[OmniOS-discuss] OmniOS based redundant NFS

[sergey ivanov]

Thanks, Stephan.
I did a simple test with creating lu over physical disks for use as
ISSI targets, and it worked well. I am going to directly connect 2
servers and export their disks as separate I SCSI targets. Or maybe
different LUNs in a target. And then on the active server start
initiator to get these targets, and combine them into a pool of 2-way
mirrors so that it stays degraded but working if one of the servers
dies.
So, manual failover for this configuration will be the following. If
the server to be disabled is still active, stop NFS, export zpool on
it, stop iscsiadm, release shared IP. On the other server: import
zpool and start NFS, activate shared IP.
I read once there are some tricks which make clients do not recognize
NFS server is changed underneath all mounts, but I never tried it.
-- 
  Regards,
  Sergey Ivanov.

Regards,
Sergey Ivanov


On Thu, Sep 28, 2017 at 12:49 AM, Stephan Budach <stephan.budach at jvm.de> wrote:
> Hi Sergey,
>
> ----- Ursprüngliche Mail -----
>> Von: "sergey ivanov" <sergey57 at gmail.com>
>> An: "Stephan Budach" <stephan.budach at jvm.de>
>> CC: "omnios-discuss" <omnios-discuss at lists.omniti.com>
>> Gesendet: Mittwoch, 27. September 2017 23:15:49
>> Betreff: Re: [OmniOS-discuss] OmniOS based redundant NFS
>>
>> Thanks, Stephan!
>>
>> Please, explain "The reason to use two x two separate servers is,
>> that
>> the mirrored zpool's vdevs look the same on each NFS head".
>>
>> I understand that, if I want to have the same zpool based on iscsi
>> devices, I should not mix local disks with iscsi target disks.
>>
>> But I think I can have 2 computers, each exporting a set of local
>> disks as iscsi targets. And to have iscsi initiators on the same
>> computers importing these targets to build zpools.
>>
>> Also, looking at sbdadm, I think I can 'create lu
>> /dev/rdsk/c0t0d3s2'.
>>
>> Ok, I think I would better try it and report how it goes.
>
> Actually, things can become quite complex, I'd like to reduce the "mental" involvement to the absolute minimum, mainly because we often faced a situation where something would suddenly break, which had been running for a long time without problems. This is when peeple start… well maybe not panicking, but having to recap what the current setup was like and what they had to do to tackle this.
>
> So, uniformity is a great deal of help on such systems - at least for us. Technically, there is no issue with mixing local and remote iSCST targets on the same node, which serves as an iSCSI target and a NFS head.
>
> Also, if one of the nodes really goes down, you will be loosing your failover NFS head as well, maybe not a big deal and depending on your requirements okay. I do have such a setup as well, although only for an archive ZPOOL, where I can tolerate this reduced redundancy for the benefit of a more lightweight setup.
>
> Cheers,
> Stephan