| 1 |
> 1. Are there reliability issues surrounding this technology in Gentoo? |
| 2 |
|
| 3 |
My only experience is with a Gentoo-based iSCSI target (ie. "server"); |
| 4 |
my clients are windows-based. The system is a low-end Core 2 duo running |
| 5 |
the latest stable kernel and Iscsi Enterprise Target; I have been |
| 6 |
running this setup non-stop for a couple of years and it has proven |
| 7 |
quite stable. |
| 8 |
|
| 9 |
iSCSI is designed with a dedicated, reliable network in mind, and in my |
| 10 |
experience it is quite sensitive to network connectivity issues. It is |
| 11 |
best used over gigabit ethernet; fast ethernet is ok, too, if you don't |
| 12 |
care about performace. Avoid WiFi if you value your data (and your |
| 13 |
mental health) |
| 14 |
|
| 15 |
> 2. Are there any howtos about putting as much of the file-system as |
| 16 |
> possible onto an iSCSI device. |
| 17 |
|
| 18 |
Google "root over iscsi". For example: |
| 19 |
|
| 20 |
http://wpkg.org/Diskless_/_remote_boot_with_Open-iSCSI |
| 21 |
|
| 22 |
I have _not_ tried it. It is an interesting concept, but I think that |
| 23 |
the OS is better left on a local disk -- the performance penalty is way |
| 24 |
too great, especially with the king of budget-oriented storage backend |
| 25 |
you are considering. |
| 26 |
|
| 27 |
> 3. What's the best (most lightweight) way to expose the disk as a |
| 28 |
> block device. I don't want to manage three fully-fledged Linux boxes. |
| 29 |
|
| 30 |
The only software you need is an iSCSI initiator: a minimal Gentoo |
| 31 |
install running sys-block/iscsitarget is enough. |
| 32 |
|
| 33 |
IET allows you to export any kind of raw block device (a disk, a |
| 34 |
partition, a RAID volume,...) or even a file on a local filesystem. |
| 35 |
|
| 36 |
Or perhaps you can look into FreeNAS (http://freenas.org), which is less |
| 37 |
flexible than a full-fledged OS install but might be enough in your case. |
| 38 |
|
| 39 |
> Can (cheap) NAS devices be used to export iSCSI to Gentoo? |
| 40 |
|
| 41 |
If the NAS device can "speak" iSCSI, well, yes. |
| 42 |
|
| 43 |
> 4. What would be the strategy to 'secure' this iSCSI device... it would |
| 44 |
> be a disaster if my WiFi were cracked and my data corrupted from a |
| 45 |
> non-authorised host. |
| 46 |
|
| 47 |
iSCSI connections are authenticated with a challenge-response mechanism; |
| 48 |
in IET you can also restrict access to specific hosts on a per-volume |
| 49 |
basis. That should be enough if you are not transferring the data itself |
| 50 |
over WiFi, which is a Bad Thing and should not be done. |
| 51 |
|
| 52 |
> Snap-shots, of course, are only really valuable for non-archive data... |
| 53 |
> so, in future, I could add a ZFS volume using the same iSCSI strategy. |
| 54 |
|
| 55 |
ZFS allows you to take FS-level snapshots -- with iSCSI that would be on |
| 56 |
the client, onto a network-connected volume, and I don't know what kind |
| 57 |
of performance implications that has. |
| 58 |
|
| 59 |
If you want to take snapshots on the server, my first thought would be |
| 60 |
to do so at the block level using LVM. No idea if it plays well with |
| 61 |
IET, though. |
| 62 |
|
| 63 |
andrea |
Archives