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.
Friday, August 17, 2012
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":
After running setup(new setup) or transporter.sh (upgrade/backup). Re-check/edit your POOL=poolname in /mnt/eon0/.exec.
EON 64-bit x86 CIFS ISO image version 1.0b (NO HTTPD)
New to EON, read here first! Upgrading, read here first!
For new setups, before running "setup":
cd /mnt/eon0/bin ./slinky r ./slinky c setupIf 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_POOLNAMEThis 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' .execAn 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.eonAfter 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-1.0b-151-64-cifs-min.iso ( mirror )
- MD5: 14696d625d4f686f06d1091435b80441
- Released: Wednesday 21-December-2011 (size: ~86MB)
- eon-1.0b-151-64-smb-min.iso ( mirror )
- MD5: ef26e606f9f403f94b1b12d478537be3
- Released: Wednesday 21-December-2011 (size: ~115MB)
- eon-1.0b-151-32-cifs-min.iso ( mirror )
- MD5: 1754065558dc3bf003990e7ff85f4806
- Released: Thursday 12-January-2012 (size: ~57MB)
- eon-1.0b-151-32-smb-min.iso ( mirror )
- MD5: 6aa382a2fc5f3ae4ece45d146642e48c
- Released: Thursday 12-January-2012 (size: ~87MB)
- binary kit 1.0 (Released 22-February-2012)
- rail (remote internet package installer)
- emp (EON multi-purpose program)
cd /your_zpool mv local old-local mkdir localIf this is the first time using the binary kit
cd /your_zpool mkdir localPerform 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 railWeb 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 startTransmission: 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 startPython is a requirement for SABnzbd, Sickbeard and CouchPotato.
rail install pythonSABnzbd: 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 startSickbeard: 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 startCouchPotato: 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 startNew/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.
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 ...
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
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.
The important things to note from these tests between a client (Win XP) and EON ZFS NAS server on this network are:
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 -sIn the other terminal, run (substitute your interface name for bge0)
dladm show-link bge0 -s -i 1On 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 20The 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/secOptional: 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 0With 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/secWith 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/secWith 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/secWith 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/secWith 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/secWith 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:
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 RAMThe 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.
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.tgzNext, 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.shLet'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.shIf 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.
Binary Kit 130 summary:
cd /tmp wget -O binkit-130.tgz http://i.minus.com/1323745623/7Aw7618NGr6qYvgEXEpkWw/dZLxUEf3SOTLh.tgzIf 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 localThis 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:
- PHP/libphp 5.3.1 (GD, jpeg, png support)
- Aria2c 1.9.3 (HTTP/HTTPS, FTP, BitTorrent and Metalink)
- tmux 1.1 (terminal multiplexer)
- screen (terminal multiplexer)
- wget/curl (retrieving files using HTTP, HTTPS and FTP)
- glusterfs 3.0 (clustered storage solution)
- stunnel (encrypt TCP connections inside SSL)
- socat (multi-purpose relay)
- bonnie/iperf (disk / network benchmarking)
- nano (editor)
- elinks (text browser)
- ddclient/inadyn (dynamic DNS clients)
- par2 (parity archive volume set)
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:
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
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"
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-0.600-130-64-cifs.iso
- MD5: 55c5837985f282f9272f5275163f7d7b
- Size: ~93Mb
- Released: Monday 05-April-2010
EON 64-bit x86 Samba ISO image version 0.60.0 based on snv_130
- eon-0.600-130-64-smb.iso
- MD5: bf095f2187c29fb543285b72266c0295
- Size: ~106Mb
- Released: Monday 05-April-2010
EON 32-bit x86 CIFS ISO image version 0.60.0 based on snv_130
- eon-0.600-130-32-cifs.iso
- MD5: e2b312feefbfb14792c0d190e7ff69cf
- Size: ~59Mb
- Released: Monday 05-April-2010
EON 32-bit x86 Samba ISO image version 0.60.0 based on snv_130
- eon-0.600-130-32-smb.iso
- MD5: bcf6dc76bc9a22cff1431da20a5c56e2
- Size: ~73Mb
- Released: Monday 05-April-2010
EON 64-bit x86 CIFS ISO image version 0.60.0 based on snv_130 (NO HTTPD)
- eon-0.600-130-64-cifs-min.iso
- MD5: f5922c98888521e4d8bef10133ccbe40
- Size: ~87Mb
- Released: Monday 05-April-2010
EON 64-bit x86 Samba ISO image version 0.60.0 based on snv_130 (NO HTTPD)
- eon-0.600-130-64-smb-min.iso
- MD5: e74732c41e4b3a9a06f52779bc9f8352
- Size: ~101Mb
- Released: Monday 05-April-2010
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?
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.
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.
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=532RAIDZ
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 532Both 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.
Wednesday, February 17, 2010
Traffic (QoS) control built into your EON ZFS storage
Your EON ZFS storage provides access to a lot of services, such as HTTP, HTTPS, SFTP, Firefly/daapd, AFP(AppleShare) and more. All of these services are available as a network resource. Wouldn't it be nice to be able to control or manage how different systems use these network resources, such as bandwidth?
Project Crossbow provides the controls to manage and virtual-ize network resources. The traffic controls (QoS) can be used to manage by transport (TCP, UDP, SCTP, iSCSI, etc), bandwidth limits, IP address and more.
For example, one could simply limit the amount of bandwidth the HTTP, HTTPS or SSH service can utilize. You could create virtual nics bound to your real interface and provide different levels of service and bandwith to these virtual or real nics. It allows for a very flexible storage setup where you can really manage the traffic and quality of service it delivers.
Let's do a simple 10Mbps bandwidth limit for HTTP via interface bge0 for a flow we will label httpflow. First, we create a flow that matches the HTTP service
Project Crossbow provides the controls to manage and virtual-ize network resources. The traffic controls (QoS) can be used to manage by transport (TCP, UDP, SCTP, iSCSI, etc), bandwidth limits, IP address and more.
For example, one could simply limit the amount of bandwidth the HTTP, HTTPS or SSH service can utilize. You could create virtual nics bound to your real interface and provide different levels of service and bandwith to these virtual or real nics. It allows for a very flexible storage setup where you can really manage the traffic and quality of service it delivers.
Let's do a simple 10Mbps bandwidth limit for HTTP via interface bge0 for a flow we will label httpflow. First, we create a flow that matches the HTTP service
flowadm add-flow -l bge0 -a transport=tcp,local_port=80 httpflowLet's view it
flowadm show-flowFinally, let's set bandwidth limits
flowadm set-flowprop -p maxbw=10m httpflowTo verify the properties
flowadm show-flowpropTo show traffic usage
flowadm show-usageAccounting can also be setup to record the usage. Rather than rehash the numerous possibilities, here are 2 links that details this feature fairly well. The first is written by Ben Rockwood and the other can be found here. Traffic control ... out!
Subscribe to:
Posts (Atom)
