Mirror of Raidz for data reliability

[Marcelo Araujo]

Dear Adam,

Yes, you are right!

2012/5/17 Adam Nowacki <nowakpl at platinum.linux.pl>

> My understanding of this setup is:
> - there are 2 chasis housing disks, each with a 2 port SAS expander,
> - there are 2 servers, each with a 2 port SAS HBA (1st port connected to
> 1st SAS expander, 2nd port connected to 2nd SAS expander).
>
>
> On 2012-05-17 13:17, George Kontostanos wrote:
>
>> On Thu, May 17, 2012 at 1:52 PM, George Kontostanos
>> <gkontos.mail at gmail.com>  wrote:
>>
>>> On Thu, May 17, 2012 at 3:29 AM, Marcelo Araujo<araujobsdport at gmail.com*
>>> *>  wrote:
>>>
>>>> George,
>>>>
>>>>
>>>>> If you have 2 machines then your best bet would be HAST.
>>>>>
>>>>
>>>>
>>>> So, why use ETHERNET if my Machine can see both JBOD?
>>>>
>>>
>>> I was under the impression that you are talking about 2 different
>>> physical machines.
>>>
>>>  If you are worried about data replication you can always use lagg with
>>>>> 2 or more interfaces.
>>>>>
>>>>
>>>>
>>>> It is different than data replication. It is data protection.
>>>>
>>>
>>> Storing the same data in 2 different locations is data protection.
>>>
>>> Regards
>>>
>>>
>> Ok, after reading more carefully your first post I realized what you
>> are trying to do.
>>
>> 2 Machines, 2 different controllers. Yet interconnected. So, in a way
>> both machines would be able to see both controllers.
>>
>> This is very interesting but there are some implications.
>>
>> 1) Suppose you manage to create a mirror consisted by drives on those
>> different controllers. If you reboot machine #1 machine#2 might panic.
>> It is not like loosing a drive, here we are loosing a controller.
>>
>> 2) Both machines have to be online and the pool has to be mounted
>> readonly on the standby! You don't want both of them to accidentally
>> write at the same pool.
>>
>> 3) HAST requires tcp to work therefore it is a no go. HAST also works
>> in the vdev level. Therefore the resources should not be online on the
>> standby server.
>>
>> Good luck, this is certainly very interesting.
>>
>>
> ______________________________**_________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/**mailman/listinfo/freebsd-fs<http://lists.freebsd.org/mailman/listinfo/freebsd-fs>
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@**freebsd.org<freebsd-fs-unsubscribe at freebsd.org>
> "
>



-- 
Marcelo Araujo
araujo at FreeBSD.org