Monday, January 21, 2013

EON ZFS Storage Appliance updates & fixes

Here it is, a refinement update and process that allows for quick fixes, patch delivery to your EON ZFS Storage Appliance. Version 1.0 introduced some portable/temporary bits (slinky) because of external dependencies like Perl, size considerations and network packaging. Based on feedback from EON Storage users, these added slinky steps were at times confusing and troublesome. This update (details here) moves to eliminate the extra steps, moves closer to eliminate dependency on external bits(setup will no longer depend on Perl) and provides numerous refinement fixes for installation, setup, upgrading. Keep the feedback and ideas coming. There's more to come, storing the exciting year ahead!

Friday, August 17, 2012

EON + KVM gives Win 7, FreeNAS and Linux the boot!

EON with the addition of KVM hypervisor is shown giving the "boot" to a Win 7, FreeNAS, and Damn Small Linux. Also booted itself. This is still in early development and testing.

Wednesday, December 21, 2011

EON ZFS Storage 1.0Beta based on oi 151a release!

I promised everyone patiently awaiting the new release, a pre Dec 25th gift and HERE IT IS!!! Lots of hard work went into giving this release life. It has undergone many hours testing so I could deliver another "rock solid" release. This build, required 2 virtual machines, 3 physical test machines and 3 compilers. Please enjoy and feel free to post feedback or any anomalies encountered. I hope EON continues to store all your precious digital moments!










New to EON, read here first! Upgrading, read here first!
For new setups, before running "setup":
cd /mnt/eon0/bin
./slinky r
./slinky c
setup
If your EON Storage is internet connected. The EON ISO can be retrieved using wget.
After running setup(new setup) or transporter.sh (upgrade/backup). Re-check/edit your POOL=poolname in /mnt/eon0/.exec.
export POOL=YOUR_POOLNAME
This is an option to edit "YOUR_POOLNAME" with a simple command if you wish to avoid "vi" (substitute your pool name where "YOUR_POOLNAME" appears). A backup file will be saved as .exec.bak
cd /mnt/eon0
sed -i.bak 's|=abyss|=YOUR_POOLNAME|g' .exec
An alternate upgrade option, using a spare USB key. Perform a new setup and then a forced zpool import to test. Perform the necessary tests and make sure all is ok before running:
zpool import -a -f
updimg.sh /mnt/eon0/boot/x86.eon
After running the new install for a few days and triple checking everything is ok. Only zpool/zfs upgrade is left, to access the new features of zpool version 28 and zfs version 5. Note that once zpool/zfs upgrade is done, there is NO GOING BACK to the older version.
zpool upgrade poolname
zfs upgrade -r poolname

EON 64-bit x86 CIFS ISO image version 1.0b (NO HTTPD)
EON 64-bit x86 Samba ISO image version 1.0b (NO HTTPD)
EON 32-bit x86 CIFS ISO image version 1.0b (NO HTTPD)
EON 32-bit x86 Samba ISO image version 1.0b (NO HTTPD)
Binary Kit 1.0:
  • binary kit 1.0 (Released 22-February-2012)
  • rail (remote internet package installer)
  • emp (EON multi-purpose program)
Pre-requisite: If you had a previous binary kit installed
cd /your_zpool
mv local old-local
mkdir local
If this is the first time using the binary kit
cd /your_zpool
mkdir local
Perform the following on the EON command line to install the latest binary kit, remote installer and more. Most of these steps are one time only to add the bits that were not ready at release time. They will be self updating from here on. You can simply copy and paste 1 line at a time in an ssh session. Run "rail" to see more usage options.
cd /mnt/eon0/bin
./slinky wget
wget -q -U mozilla -O slinky http://bit.ly/zNY7rI
wget -q -U mozilla -O md5sum http://bit.ly/xwQZU3
wget -q -U mozilla -O /usr/bin/rail http://bit.ly/yqck53
chmod 755 md5sum slinky /bin/rail
./slinky md5
rail install emp
rail install binkit
rail install perl
rail
Web Server: Installing a web server (apache, lighttpd or nginx). Browse to your IP after starting a web server to see links to various apps. Run "emp" to see usage options. More detailed how to here.
rail install apache
certgen.sh (to generate unique self-signed certificate) 
emp apache start
Transmission: Edit /usr/local/transmission/settings.json to allow your client IP before starting Transmission Bit Torrent client
rpc-whitelist": "127.0.0.1,IP_address_of_client",
rpc-whitelist": "127.0.0.1,10.1.1.5",
emp transmission start
Python is a requirement for SABnzbd, Sickbeard and CouchPotato.
rail install python
SABnzbd: Installing and starting SABnzbd. More detailed how to here.
cd /tmp
wget -O sabnzbd.tar.gz http://sourceforge.net/projects/sabnzbdplus/files/sabnzbdplus/sabnzbd-0.6.15/SABnzbd-0.6.15-src.tar.gz/download
gzip -dc sabnzbd.tar.gz | tar -xf -
mv SABnzbd-0.6.15 /usr/local/sabnzb
emp sabnzb start
Sickbeard: Installing and starting Sickbeard. More detailed how to here.
cd /tmp
wget -O sickbeard.tar.gz --no-check-certificate https://github.com/midgetspy/Sick-Beard/tarball/master
gzip -dc sickbeard.tar.gz | gtar -xf -
mv midgetspy-Sick-Beard-911f5d1 /usr/local/sickbeard
emp sickbeard start
CouchPotato: Installing and starting CouchPotato. More detailed how to here.
cd /tmp
wget -O couchpotato.zip --no-check-certificate https://github.com/RuudBurger/CouchPotato/zipball/master
unzip -q -aa couchpotato.zip
mv RuudBurger-CouchPotato-6970c10 /usr/local/couchpotato
emp couchpotato start 
New/Changes/Fixes:
  • New ZPOOL (version 28) and ZFS (version 5)
  • Perl 5.10.0 (full version, user customizable) moved to the binary kit, requires a new setup step (slinky)
  • New Binary Kit is semi-mandatory (needed for S.M.A.R.T and more)
  • New/Updated administration and statistics binaries.
  • Simple appliance package downloader and installer (more info to come)
  • kernel line addition "-B disable-pcieb=true" under VMware. ESXi, Fusion, no longer required.
 S T O R E   I T   Y O U R   W A Y !

Sunday, October 23, 2011

Thoughts on a beta release of EON ZFS Storage

It's been a while since the last EON release but we are almost there. It's been a road of many trials with IPS and patience from the EON community but we are almost at a polished new release. I'm planning a beta release based on Openindiana/Illumos 151 bits. The beta will give the community a chance to provide feedback, input and possibly changes (bugs what bugs) for the actual release.
There are numerous improvements and binary additions with 151 (dladm, ipadm, smbstat, dtrace 1.7, etc). With these changes, come additional dependencies and an increase in package size, which goes against EON's goals.

Here's a current list of changes. Of course I'd like to hear your input, feedback and comments.
Perl has been moved to the binary kit. For memory size considerations, better performance and a user modifiable perl, it was shifted from the EON (embedded) to a wget install. The version of perl has changed from 5.8.4 to 5.10.0.
Pros: Lower memory footprint, better performance, user modifiable perl, full version.
Cons: The binary kit is no longer optional, it's now a requirement.
Options: Stick with the minimal perl bits required for (kstat, lgrpinfo, psrinfo, etc to work)

The Samba version of EON has grown considerably in size (approx 100Mb). This has me thinking to go with a pure storage OS model which means pushing Apache to the binary kit. So, Apache web server, would be a wget added choice along with nginx and lighttpd.
Pros: Lower memory footprint, better performance, two less image to release.
Cons: Future web admin (any takers) would require some kind of CLI kickstart.
Options: Leave apache embedded and Samba users basically eat the memory footprint.

Update 11.21.11: Compile-a-thon this past weekend new Binary Kit 75% complete, included goodies so far, Transmission bit torrent, Netatalk AFP(LION compatible), FFMPEG, RTMP server ...

Update 12.02.11: Re-compile-a-thon on again. Found some lib linking errors that requires a massive redo of most of the binary kit. Updated/Added APCupsd, SABnzbd and Sickbeard ...
Thanks to all EON users who have sent in feedback on how EON Storage is working for you. EON will continue allowing to, store it your way.

Thursday, October 6, 2011

The Definition of Innovation

Wednesday October 5th, 2011 marks a dark day, as the world lost a true technologist. He showed us that "innovation distinguishes between a leader and a follower". "The only way to do great work is to love what you do. If you haven’t found it yet, keep looking. Don’t settle. As with all matters of the heart, you’ll know when you find it". He lead by example, walked the talk and delivered unmatched standards of quality and excellence in what he shared. I never had an opportunity meet him, but "I would trade all of my technology for an afternoon with" him. For all you shared, Thank You Steve ...

Thursday, June 9, 2011

The IPS state of EON ZFS NAS Build

It's been a while since there's been an update. Well, after a great deal of hard, slow work, I have some good and bad news. I'll start with the good news. The good news is, there's a booting, 99.7% functional snv 151a based version of EON. The bad news is, this version is not distributable as it's built from Oracle repositories. I decided to use Oracle's repository as a test of process when I could not get a booting Illumos or Openindiana based version. They all panic and reboot after loading the kernel. The good thing here is the process building an IPS image seems to work. So it means back to trying with Illumos and Openindiana. Here are some screenshots of the snv 151a version.
ipadm (new)
ptree










smbstat (new)
zpool version

Friday, March 25, 2011

EON ZFS Storage on a HP Proliant MicroServer

I received the following pictures from a EON ZFS storage user, Nasir (thanks), confirming EON running fine on the HP Proliant Microserver. A few people have made inquiries about EON and compatibility with this hardware so this may help with your build plans. Again, I don't own the hardware so I have not thoroughly tested it but seems the network interface, zpool members and number of CPU cores register correctly. The HP Proliant MicroServer (more details) is a mini-itx form factor and supports up to 8GB of ECC RAM. Go ahead, store it your way ...
Broadcom nics work
EON on HP MicroServer


1.3Ghz x 2 cores online
zpool + disk members

Saturday, December 4, 2010

Benchmarking EON ZFS NAS performance (Part I)

At some point you may want to know if your EON ZFS storage is performing on par with your hardware's specifications/setup or if it is doing otherwise. Using various (prerequisite) binary kit tools we can identify if network and I/O performance are optimal or working within expectations. We will use the following tools for our testing
Iperf (Mac, Win)
IOMeter [Part II]
In most cases your storage is accessed/utilized across a network using a client PC. So testing will involve a source, destination and the network that connects them. The source will be your client PC and the destination will be your EON ZFS storage. This will help identify what the network is capable of, is it working properly or if it is a bottleneck to your storage.

On the EON ZFS storage (destination), connect 2 terminals using ssh or putty sessions from your client (Win XP in this case). In one terminal, run
iperf -s
In the other terminal, run (substitute your interface name for bge0)
dladm show-link bge0 -s -i 1
On the source or client PC we will run repetitions of below, changing TCP window size
iperf -c IP_of_EON -P 1 -i 1 -w 8k -f m -t 20
The above says, run 1 process thread P=1 for a test duration of t=20secs with interval i=1sec updates and a TCP window size w=8 in kilobytes. The results will be formatted in (m) megabytes.

This will produce an output showing the upper bounds of your network between the source and destination. It may also help identify the optimal TCP window size for your network. The output below will show the different transfer rates with each change of the TCP window size from 8k to 64k, on the client on a gigabit network. So lets begin.
C:\download>iperf -c 10.72.100.148 -P 1 -i 1 -w 8k -f m -t 20
------------------------------------------------------------
Client connecting to 10.72.100.148, TCP port 5001
TCP window size: 0.01 MByte
------------------------------------------------------------
[1912] local 10.72.100.128 port 3448 connected with 10.72.100.148 port 5001
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0- 1.0 sec  25.2 MBytes   211 Mbits/sec
[1912]  1.0- 2.0 sec  24.7 MBytes   207 Mbits/sec
[1912]  2.0- 3.0 sec  25.4 MBytes   213 Mbits/sec
[1912]  3.0- 4.0 sec  24.1 MBytes   202 Mbits/sec
[1912]  4.0- 5.0 sec  23.8 MBytes   200 Mbits/sec
[1912]  5.0- 6.0 sec  24.0 MBytes   201 Mbits/sec
[1912]  6.0- 7.0 sec  25.0 MBytes   210 Mbits/sec
[1912]  7.0- 8.0 sec  25.0 MBytes   210 Mbits/sec
[1912]  8.0- 9.0 sec  25.5 MBytes   214 Mbits/sec
[1912]  9.0-10.0 sec  24.1 MBytes   202 Mbits/sec
[1912] 10.0-11.0 sec  24.8 MBytes   208 Mbits/sec
[1912] 11.0-12.0 sec  25.1 MBytes   211 Mbits/sec
[1912] 12.0-13.0 sec  25.3 MBytes   212 Mbits/sec
[1912] 13.0-14.0 sec  23.1 MBytes   194 Mbits/sec
[1912] 14.0-15.0 sec  23.6 MBytes   198 Mbits/sec
[1912] 15.0-16.0 sec  23.6 MBytes   198 Mbits/sec
[1912] 16.0-17.0 sec  25.4 MBytes   213 Mbits/sec
[1912] 17.0-18.0 sec  25.6 MBytes   215 Mbits/sec
[1912] 18.0-19.0 sec  25.2 MBytes   211 Mbits/sec
[1912] 19.0-20.0 sec  25.0 MBytes   210 Mbits/sec
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0-20.0 sec  494 MBytes    207 Mbits/sec
Optional: Run on EON to compare network interface statistics
dladm show-link bge0 -s -i 1
LINK           IPACKETS  RBYTES   IERRORS  OPACKETS    OBYTES      OERRORS
bge0           19447     27628795 0        2432        155854      0
bge0           19089     27123001 0        2382        152546      0
bge0           19638     27886729 0        2450        156898      0
bge0           18652     26493270 0        2326        148962      0
bge0           18454     26205800 0        2301        147362      0
bge0           18561     26358926 0        2315        148258      0
bge0           19268     27372463 0        2404        153954      0
bge0           19379     27533495 0        2418        154850      0
bge0           19687     27977035 0        2457        157346      0
bge0           18681     26527515 0        2330        149218      0
bge0           19155     27208916 0        2390        153058      0
bge0           19419     27593183 0        2423        155170      0
bge0           19542     27757561 0        2438        156130      0
bge0           17840     25347308 0        2226        142562      0
bge0           18148     25776206 0        2264        144994      0
bge0           18353     26072730 0        2290        146658      0
bge0           19657     27919866 0        2452        157106      0
bge0           19756     28065895 0        2465        157858      0
bge0           19390     27542355 0        2419        154914      0
bge0           17889     25407434 0        2236        143362      0
bge0           38        8169     0        1           162         0
With TCP window set to 8K, Max throughput is approx 207Mbps/8bps=25.87MB/s
C:\download>iperf -c 10.72.100.148 -P 1 -i 1 -w 16k -f m -t 20
------------------------------------------------------------
Client connecting to 10.72.100.148, TCP port 5001
TCP window size: 0.02 MByte
------------------------------------------------------------
[1912] local 10.72.100.128 port 3487 connected with 10.72.100.148 port 5001
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0- 1.0 sec  40.1 MBytes   336 Mbits/sec
[1912]  1.0- 2.0 sec  31.1 MBytes   261 Mbits/sec
[1912]  2.0- 3.0 sec  36.3 MBytes   305 Mbits/sec
[1912]  3.0- 4.0 sec  43.2 MBytes   363 Mbits/sec
[1912]  4.0- 5.0 sec  43.2 MBytes   363 Mbits/sec
[1912]  5.0- 6.0 sec  41.5 MBytes   348 Mbits/sec
[1912]  6.0- 7.0 sec  41.9 MBytes   352 Mbits/sec
[1912]  7.0- 8.0 sec  29.6 MBytes   249 Mbits/sec
[1912]  8.0- 9.0 sec  33.2 MBytes   278 Mbits/sec
[1912]  9.0-10.0 sec  34.4 MBytes   288 Mbits/sec
[1912] 10.0-11.0 sec  37.5 MBytes   315 Mbits/sec
[1912] 11.0-12.0 sec  41.4 MBytes   348 Mbits/sec
[1912] 12.0-13.0 sec  43.0 MBytes   360 Mbits/sec
[1912] 13.0-14.0 sec  30.9 MBytes   259 Mbits/sec
[1912] 14.0-15.0 sec  39.2 MBytes   329 Mbits/sec
[1912] 15.0-16.0 sec  42.9 MBytes   360 Mbits/sec
[1912] 16.0-17.0 sec  42.9 MBytes   360 Mbits/sec
[1912] 17.0-18.0 sec  40.6 MBytes   340 Mbits/sec
[1912] 18.0-19.0 sec  37.2 MBytes   312 Mbits/sec
[1912] 19.0-20.0 sec  24.7 MBytes   207 Mbits/sec
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0-20.0 sec  755 MBytes    317 Mbits/sec
With TCP window set to 16K, Max throughput is approx 317Mbps/8bps=39.63MB/s
C:\download>iperf -c 10.72.100.148 -P 1 -i 1 -w 24k -f m -t 20
------------------------------------------------------------
Client connecting to 10.72.100.148, TCP port 5001
TCP window size: 0.02 MByte
------------------------------------------------------------
[1912] local 10.72.100.128 port 3497 connected with 10.72.100.148 port 5001
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0- 1.0 sec  53.4 MBytes   448 Mbits/sec
[1912]  1.0- 2.0 sec  50.2 MBytes   421 Mbits/sec
[1912]  2.0- 3.0 sec  40.8 MBytes   343 Mbits/sec
[1912]  3.0- 4.0 sec  62.5 MBytes   524 Mbits/sec
[1912]  4.0- 5.0 sec  63.9 MBytes   536 Mbits/sec
[1912]  5.0- 6.0 sec  63.4 MBytes   532 Mbits/sec
[1912]  6.0- 7.0 sec  64.4 MBytes   540 Mbits/sec
[1912]  7.0- 8.0 sec  58.7 MBytes   493 Mbits/sec
[1912]  8.0- 9.0 sec  48.0 MBytes   403 Mbits/sec
[1912]  9.0-10.0 sec  62.2 MBytes   522 Mbits/sec
[1912] 10.0-11.0 sec  54.1 MBytes   454 Mbits/sec
[1912] 11.0-12.0 sec  53.9 MBytes   452 Mbits/sec
[1912] 12.0-13.0 sec  56.8 MBytes   477 Mbits/sec
[1912] 13.0-14.0 sec  57.6 MBytes   483 Mbits/sec
[1912] 14.0-15.0 sec  49.1 MBytes   412 Mbits/sec
[1912] 15.0-16.0 sec  65.0 MBytes   545 Mbits/sec
[1912] 16.0-17.0 sec  64.2 MBytes   539 Mbits/sec
[1912] 17.0-18.0 sec  64.6 MBytes   542 Mbits/sec
[1912] 18.0-19.0 sec  64.0 MBytes   537 Mbits/sec
[1912] 19.0-20.0 sec  57.5 MBytes   483 Mbits/sec
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0-20.0 sec  1154 MBytes   484 Mbits/sec
With TCP window set to 24K, Max throughput is approx 484Mbps/8bps=60.5MB/s
C:\download>iperf -c 10.72.100.148 -P 1 -i 1 -w 32k -f m -t 20
------------------------------------------------------------
Client connecting to 10.72.100.148, TCP port 5001
TCP window size: 0.03 MByte
------------------------------------------------------------
[1912] local 10.72.100.128 port 3500 connected with 10.72.100.148 port 5001
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0- 1.0 sec  77.0 MBytes   646 Mbits/sec
[1912]  1.0- 2.0 sec  78.2 MBytes   656 Mbits/sec
[1912]  2.0- 3.0 sec  48.9 MBytes   410 Mbits/sec
[1912]  3.0- 4.0 sec  76.6 MBytes   642 Mbits/sec
[1912]  4.0- 5.0 sec  75.8 MBytes   636 Mbits/sec
[1912]  5.0- 6.0 sec  79.4 MBytes   666 Mbits/sec
[1912]  6.0- 7.0 sec  78.8 MBytes   661 Mbits/sec
[1912]  7.0- 8.0 sec  79.0 MBytes   663 Mbits/sec
[1912]  8.0- 9.0 sec  66.7 MBytes   559 Mbits/sec
[1912]  9.0-10.0 sec  81.0 MBytes   679 Mbits/sec
[1912] 10.0-11.0 sec  76.8 MBytes   644 Mbits/sec
[1912] 11.0-12.0 sec  79.5 MBytes   667 Mbits/sec
[1912] 12.0-13.0 sec  74.1 MBytes   621 Mbits/sec
[1912] 13.0-14.0 sec  72.9 MBytes   612 Mbits/sec
[1912] 14.0-15.0 sec  70.0 MBytes   587 Mbits/sec
[1912] 15.0-16.0 sec  79.1 MBytes   663 Mbits/sec
[1912] 16.0-17.0 sec  79.6 MBytes   668 Mbits/sec
[1912] 17.0-18.0 sec  79.6 MBytes   668 Mbits/sec
[1912] 18.0-19.0 sec  79.4 MBytes   666 Mbits/sec
[1912] 19.0-20.0 sec  77.7 MBytes   652 Mbits/sec
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0-20.0 sec  1510 MBytes   633 Mbits/sec
With TCP window set to 32K, Max throughput is approx 633Mbps/8bps=79.13MB/s
C:\download>iperf -c 10.72.100.148 -P 1 -i 1 -w 48k -f m -t 20
------------------------------------------------------------
Client connecting to 10.72.100.148, TCP port 5001
TCP window size: 0.05 MByte
------------------------------------------------------------
[1912] local 10.72.100.128 port 3506 connected with 10.72.100.148 port 5001
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0- 1.0 sec   101 MBytes   846 Mbits/sec
[1912]  1.0- 2.0 sec   102 MBytes   852 Mbits/sec
[1912]  2.0- 3.0 sec  84.9 MBytes   712 Mbits/sec
[1912]  3.0- 4.0 sec  81.7 MBytes   686 Mbits/sec
[1912]  4.0- 5.0 sec  94.7 MBytes   794 Mbits/sec
[1912]  5.0- 6.0 sec   103 MBytes   860 Mbits/sec
[1912]  6.0- 7.0 sec   102 MBytes   859 Mbits/sec
[1912]  7.0- 8.0 sec   102 MBytes   852 Mbits/sec
[1912]  8.0- 9.0 sec   101 MBytes   850 Mbits/sec
[1912]  9.0-10.0 sec  90.6 MBytes   760 Mbits/sec
[1912] 10.0-11.0 sec  82.6 MBytes   693 Mbits/sec
[1912] 11.0-12.0 sec   101 MBytes   848 Mbits/sec
[1912] 12.0-13.0 sec  85.5 MBytes   717 Mbits/sec
[1912] 13.0-14.0 sec  85.8 MBytes   719 Mbits/sec
[1912] 14.0-15.0 sec  91.5 MBytes   767 Mbits/sec
[1912] 15.0-16.0 sec  91.8 MBytes   770 Mbits/sec
[1912] 16.0-17.0 sec  89.7 MBytes   753 Mbits/sec
[1912] 17.0-18.0 sec   102 MBytes   858 Mbits/sec
[1912] 18.0-19.0 sec  97.9 MBytes   821 Mbits/sec
[1912] 19.0-20.0 sec   100 MBytes   841 Mbits/sec
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0-20.0 sec  1891 MBytes   793 Mbits/sec
With TCP window set to 48K, Max throughput is approx 793Mbps/8bps=99.13MB/s
C:\download>iperf -c 10.72.100.148 -P 1 -i 1 -w 64k -f m -t 20
------------------------------------------------------------
Client connecting to 10.72.100.148, TCP port 5001
TCP window size: 0.06 MByte
------------------------------------------------------------
[1912] local 10.72.100.128 port 3538 connected with 10.72.100.148 port 5001
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0- 1.0 sec  98.2 MBytes   823 Mbits/sec
[1912]  1.0- 2.0 sec  66.3 MBytes   556 Mbits/sec
[1912]  2.0- 3.0 sec   101 MBytes   844 Mbits/sec
[1912]  3.0- 4.0 sec  99.8 MBytes   837 Mbits/sec
[1912]  4.0- 5.0 sec  99.5 MBytes   835 Mbits/sec
[1912]  5.0- 6.0 sec  79.7 MBytes   668 Mbits/sec
[1912]  6.0- 7.0 sec  76.6 MBytes   643 Mbits/sec
[1912]  7.0- 8.0 sec  94.1 MBytes   790 Mbits/sec
[1912]  8.0- 9.0 sec   101 MBytes   846 Mbits/sec
[1912]  9.0-10.0 sec   100 MBytes   840 Mbits/sec
[1912] 10.0-11.0 sec  96.7 MBytes   811 Mbits/sec
[1912] 11.0-12.0 sec  96.0 MBytes   805 Mbits/sec
[1912] 12.0-13.0 sec  94.0 MBytes   789 Mbits/sec
[1912] 13.0-14.0 sec  97.2 MBytes   816 Mbits/sec
[1912] 14.0-15.0 sec  98.5 MBytes   827 Mbits/sec
[1912] 15.0-16.0 sec  81.7 MBytes   686 Mbits/sec
[1912] 16.0-17.0 sec  74.6 MBytes   626 Mbits/sec
[1912] 17.0-18.0 sec  79.8 MBytes   669 Mbits/sec
[1912] 18.0-19.0 sec  98.1 MBytes   823 Mbits/sec
[1912] 19.0-20.0 sec  99.7 MBytes   837 Mbits/sec
[ ID] Interval        Transfer      Bandwidth
[1912]  0.0-20.0 sec  1832 MBytes   768 Mbits/sec
With TCP window set to 64K, Max throughput is approx 768Mbps/8bps=96MB/s.

The important things to note from these tests between a client (Win XP) and EON ZFS NAS server on this network are:
  • Possible upper limit near 99.13MBytes/sec (not the theoretical 1000Mbps/125MBytes/sec).
  • The optimal TCP window size for this network is probably 48K (should have tested 56K also).
  • A larger TCP window size of 64K did not provide the highest transfer rate.

Saturday, September 4, 2010

EON ZFS takes the road to Illumos

By now Oracle's leaked letter and the fate of Opensolaris, source gates closing, is probably well known. It seems that Solaris 11 will be Oracle's sole OS focus, and while it's unknown if it will be open source or not, the opensolaris community and it's users were ignored, abandoned and left facing a nasty dose of hard realities.

The options left for the opensolaris community (including EON ZFS Storage) were bleak. Sun Microsystems was built on great innovation and thanks to a previous Solaris kernel engineer Garrett D'Amore and the open-source effort called illumos, there is new hope. It's stated that illumos will be 100% community driven and owned and many smart people who are committed to opensolaris and ZFS have signed on to breathe life into this effort and free our reliance from Oracle's handouts.

EON is testing the road to illumos and I have compiled the nightly a couple of times. Some build times:
297mins/~5 hrs    Quad core Q6600 @ 2.4Ghz w/2GB RAM
52mins/~1 hr      Dual X5570 @ 2.93Ghz w/4GB RAM
The journey should be interesting ...

Tuesday, August 24, 2010

Mediatomb UPnP server on your EON ZFS NAS

MediaTomb is an open source (GPL) UPnP MediaServer with a nice web user interface. It allows you to stream your digital media across your home network and listen to/watch it on a variety of UPnP compatible devices. Mediatomb is now available for your EON ZFS NAS in the download section (mtombaa, mtombab) and can be added using the following steps. The binary kit MUST be installed for mediatomb to work.

So let's get started by downloading and re-assembling the mediatomb package.
NOTE: The following steps should be performed as user id "root" unless otherwise specified.
cd /tmp
wget -O mtombaa http://sites.google.com/site/eonstorage/downloads/mtombaa?attredirects=0&d=1
wget -O mtombab http://sites.google.com/site/eonstorage/downloads/mtombab?attredirects=0&d=1
cat mtomba[a-z] > mtomb.tgz
Next, let's create the necessary directories and unpack the mediatomb package.
cd /abyss
mkdir mediatomb
cd mediatomb
gzip -dc /tmp/mtomb.tgz | tar -xf -
Let's add the following entries to /mnt/eon0/.exec, so mediatomb will start automatically when the EON ZFS NAS is booted.
# mediatomb section
(cd /opt ; ln -s ../${POOL}/mediatomb .)
[ -x /opt/mediatomb/bin/start_mtomb.sh ] && /opt/mediatomb/bin/start_mtomb.sh
Let's create the mediatomb logging, database and configuration directories. Also get the start up script (start_mtomb.sh)
mkdir etc log
cd bin
wget -O start_mtomb.sh http://sites.google.com/site/eonstorage/downloads/start_mtomb.sh?attredirects=0&d=1
chmod 755 start_mtomb.sh
(cd /opt ; ln -s ../abyss/mediatomb .)
And finally, to start mediatomb.
/opt/mediatomb/bin/start_mtomb.sh
If all went well, you can point a browser to EON NAS http://ip:49152/ and you should see a image similar to the image below. Let the movie streaming begin.
Mediatomb UPnP server on EON ZFS NAS

Tuesday, July 27, 2010

Compiling rsync and your own binaries for EON

You have probably noticed xsconf.program (eg xsconf.rsync) name in the download section and wondered how it's used? Here's a video that will hopefully answer that and help if you wish to compile your own binaries (eg rsync) or other open source packages. The notes.program name (eg notes.rsync) contains where to get the source code and any notes/tips/edits needed for a successful compile. A pre-requisite for this exercise is a sunstudio 12 and/or gcc compiler. After the compilers are downloaded and installed on a solaris/unix system you can follow the steps in the video. Most likely you will need both sunstudio and gcc, as some code will not properly compile with the Sunstudio compiler. To build the best optimized binaries, I personally always try to use the SunStudio compiler and linker. Enough of the boring details, on with building a 64-bit version of rsync. Happy compiling ...

Tuesday, June 8, 2010

EON 0.60 ZFS binary kit snv_130 released!

Here it is finally, the long awaited EON 0.60 binary kit release based on snv_130 and other GNU compiled binaries. Hopefully, it was well worth the wait. I tried to complete all the requests for various packages but was unable to integrate them all cleanly (sabnzbd + dependency python) in this release. I will try to get the missed ones at a later time. It is uploaded in 5 parts. You can download bin-130a[a-e] manually and transfer all 5 files to your EON storage for installation or follow the steps below, which assumes you are using wget from an prior installed binary kit 124. So let's retrieve the files. These steps also assume your EON storage can reach the web.
cd /tmp
wget -O binkit-130.tgz http://i.minus.com/1323745623/7Aw7618NGr6qYvgEXEpkWw/dZLxUEf3SOTLh.tgz
If this is the first time using a binary kit, you will need to perform this step. If you have used previous binary kits, you can skip to the next step.
cd /zpool
mkdir local
This step installs the new binary kit to /usr/local which is linked to /zpool_name/local.
cd /usr/local
gzip -dc /tmp/binkit-130.tgz | tar -xf -
This completes the binary kit install and typing "aria2c -v" should confirm if it worked. Below is a screenshot listing some of the binaries included:
Binary Kit 130 summary:
This does not show powertop and top which have to be manually symlinked for now. See the notes regarding top here. The same is needed for powertop. For 32 bit EON version (To check the EON version you are running, "isainfo -kv"):
cd /usr/local/bin
ln -s ./i86/powertop .
For 64 bit EON version:
cd /usr/local/bin
ln -s ./amd64/powertop .

Wednesday, May 5, 2010

EON on a ZFS mirrored boot/root?

A typical operating system requires a boot disk and certain storage requirements to reside, boot and do what it's designed to do. The OS or boot disk where the operating system resides in a conventional install becomes a possible point of failure. The OS disk failing, would cause an outage and cut-off access to your data and storage appliance. RAID 1 or mirroring of the OS disk is often used to address/counter this type of failure. ZFS has the features to make an OS disk redundant by mirror-ing (RAID 1), providing an added layer of insurance to your storage appliance's uptime.

A design decision with EON, was to make it run from a RAM disk, hence it would not have an associated failure attached to the media(USB, CF or hard disk) it boots from or resides on. Size becomes a disadvantage running from a RAM disk but the trade off is an add layer of insurance, resilience and uptime. EON uses the boot/residence media mostly for out of band task that are not tied to performance and are not frequently used, so the typical 5+ MB/s performance of a USB/CF media is not a problem. After EON is booted, the USB media could be pulled (simulating a boot disk failure) and only the services below would be impacted. The important thing to note is that EON would continue to run, along with all the services enabled. The show goes on and facilitates dynamic repair or correction of the disk failure situation. EON uses the USB/CF media to preserve:
  • edits to the configuration files
  • edits to the grub menu entries or updating the image
  • updates to the zpool.cache
  • user optional binaries on the USB/CF media 
A ZFS boot/root was recently requested as a necessary feature/requirement for EON. I explained the resilience already built into the design and the challenges. I however gave it try the other night and succeeded in booting EON on a ZFS boot/root. This would allow the use of redundant USB/CF media. When will it be seen in a release? I'm not sure. It required using steps that were hard coded and needs more testing and refinement before it's ready for general audience and use. So yes, a ZFS boot/root for EON is possible. Here's a ZFS boot/root birth cry screenshot.

Monday, April 5, 2010

EON ZFS Storage 0.60.0 based on snv 130, Sun-set release!

Embedded Operating system/Networking (EON), RAM based live ZFS NAS appliance is released on Genunix! This release marks the end of SXCE releases and Sun Microsystems as we know it! It is dubbed the Sun-set release! Many thanks to Al at Genunix.org for download hosting and serving the Opensolaris community.

New to EON, start here! Upgrading, see how to use transporter.sh

EON Deduplication ZFS storage is available in 32 and 64-bit, CIFS and Samba versions:
EON 64-bit x86 CIFS ISO image version 0.60.0 based on snv_130

EON 64-bit x86 Samba ISO image version 0.60.0 based on snv_130

EON 32-bit x86 CIFS ISO image version 0.60.0 based on snv_130

EON 32-bit x86 Samba ISO image version 0.60.0 based on snv_130

EON 64-bit x86 CIFS ISO image version 0.60.0 based on snv_130 (NO HTTPD)

EON 64-bit x86 Samba ISO image version 0.60.0 based on snv_130 (NO HTTPD)

New/Changes/Fixes:
- Active Directory integration problem resolved
- Hotplug errors at boot are being worked on and are safe to ignore.
- Updated /mnt/eon0/.exec with new service configuration additions (light, nginx, afpd, and more ...).
- Updated ZFS, NFS v3 performance tuning in /etc/system
- Added megasys driver.
- EON rebooting at grub(since snv_122) in ESXi, Fusion and various versions of VMware workstation. This is related to bug 6820576. Workaround, at grub press e and add on the end of the kernel line "-B disable-pcieb=true"

Saturday, March 6, 2010

What's the best pool to build with 3 or 4 disks?

I've been asked many times in variations, "I just started using EON and I'm new to opensolaris, What's the best pool to build with 3 or 4 disks"? I usually answer, it depends! Credit that reflex answer to Prof. Gordon, one of the best Calculus and Differential equations teacher that walked in my time. May the force be with you, wherever you are!

I'll use Richard Elling's research to explain. Let's say I have 500Gb drives, with IOPs (for avg, small, random, cache-miss, read I/O operations per sec) = 70.59 and max media bandwidth of 133Mbytes/s(includes read and write). What can we build?
RAID Type   Disks   Sets   Storage Space   Performance (IOPS)   Max BW(Mbytes/s)
RAIDZ       4       1      3x500=1500Gb    4x70.59/3=94         3x133=399
RAIDZ       3       1      2x500=1000Gb    3x70.59/2=106        2x133=266 (1 spare)
STRIPE      4       1      4x500=2000Gb    4x70.59=282          4x133=532
STRIPE      3       1      3x500=1500Gb    3x70.59=212          3x133=399
MIRROR      2       2      2x500=1000Gb    4x70.59=282          4x133=532
RAIDZ
With 4 disks in the first raidz set, we get higher bandwidth (399Mbytes/s) vs the 3 disk raidz bandwidth (266Mbytes/s), but the 3 disk raidz pool has a higher I/O operations per second capability. Note, as "sets" are added to the 3 disk raidz (3 disks each time) the difference of IOPS between the 4 disk raidz widens. If you exhaust the usable storage space, it will cost 4 or 3 times the cost of a drive for each new "Set", to add or grow the storage. So the 3 drive raidz has a more economical cost per set. This can be repeated to add more "Sets" or more storage and bandwidth as needed. So this is a very flexible choice. The change with 1 additional set would look like.
RAID Type   Disks   Sets   Storage Space   Performance (IOPS)   Max BW(Mbytes/s)
RAIDZ       4       2      3000Gb          188                  798
RAIDZ       3       2      2000Gb          212                  532
Both 4 and 3 disk raidz allows only 1 disk to fail but if all disks had the same probability of failure then the 4 disk raidz pool would have a higher probability of a failure than the 3 disk version.

STRIPE
Has great bandwidth numbers, usable storage and IOPS, but any disk failure would cause the pool to fail and lose ALL your data. Did I mention that good storage is NOT a substitute for a GOOD backup? This pool is not easily expanded when the usable storage is exhausted and offers no data redundancy.

MIRROR
Has great bandwidth numbers, a higher cost per usable storage and allows failure of 2 disks. It has roughly twice the write bandwidth and up to 4 times the read performance as ZFS is capable of reading from all disks in the mirror in parallel. This configuration will most likely provide the best balance of performance and data protection at the expense of disks or usable storage. Expanding or growing this pool when the usable storage is being exhausted, is also simple.


Hopefully this will help architect pools that suits your workload, cost dynamics and growth needs.