SUN Open­Stor­age presentation

At work (client site) SUN made a pre­sen­ta­tion about their Open­Stor­age prod­ucts (Sun Stor­age 7000 Uni­fied Stor­age Sys­tems) today.

From a tech­nol­o­gy point of view, the soft­ware side is noth­ing new to me. Using SSDs for zfs as a read-/write-cache is some­thing we can do (part­ly) already since at least Solaris 10u6 (that is the low­est Solaris 10 ver­sion we have installed here, so I can not check quick­ly if the ZIL can be on a sep­a­rate disk in pre­vi­ous ver­sions of Solaris, but I think we have to wait until we updat­ed to Solaris 10u8 until we can have the L2ARC on a sep­a­rate disk) or in FreeB­SD. All oth­er nice ZFS fea­tures avail­able in the Open­Stor­age web inter­face are also not surprising.

But the demon­stra­tion with the Stor­age Sim­u­la­tor impressed me. The inter­ac­tion with Win­dows via CIFS makes the old­er ver­sion of files in snap­shots avail­able in Win­dows (I assume this is the Vol­ume Shad­ow Copy fea­ture of Win­dows), and the sta­tis­tics avail­able via DTrace in the web inter­face are also impres­sive. All this tech­nol­o­gy seems to be well inte­grat­ed into an easy to use pack­age for het­ero­ge­neous envi­ron­ments. If you would like to set­up some­thing like this by hand, you would need to have a lot of knowl­edge about a lot of stuff (and in the FreeB­SD case, you would prob­a­bly need to aug­ment the ker­nel with addi­tion­al DTrace probes to be able to get a sim­i­lar gran­u­lar­i­ty of the sta­tis­tics), noth­ing a small com­pa­ny is will­ing to pay.

I know that I can get a lot of infor­ma­tion with DTrace (from time to time I have some free cycles to extend the FreeB­SD DTrace imple­men­ta­tion with addi­tion­al DTrace probes for the lin­ux­u­la­tor), but what they did with DTrace in the Open­Stor­age soft­ware is great. If you try to do this at home your­self, you need some time to imple­ment some­thing like this (I do not think you can take the DTrace scripts and run them on FreeB­SD, this will prob­a­bly take some weeks until it works).

It is also the first time I see this new CIFS imple­men­ta­tion from SUN in ZFS life in action. It looks well done. Inte­gra­tion with AD looks more easy than doing it by hand in Sam­ba (at least from look­ing at the Open­Stor­age web inter­face). If we could get this in FreeB­SD… it would rock!

The entire Open­Stor­age web inter­face looks usable. I think SUN has a prod­uct there which allows them to enter new mar­kets. A prod­uct which they can sell to com­pa­nies which did not buy some­thing from SUN before (even Windows-only com­pa­nies). I think even those Win­dows admins which nev­er touch a com­mand line inter­face (read: the low-level ones; not com­pa­ra­ble at all with the real­ly high-profile Win­dows admins of our client) could be able to get this up and running.

As it seems at the moment, our client will get a Sun Stor­age F5100 Flash Array for tech­nol­o­gy eval­u­a­tion in the begin­ning of next year. Unfor­tu­nate­ly the tech­nol­o­gy looks to easy to han­dle, so I assume I have to take care about more com­plex things when this machine arrives… 🙁

Fight­ing with the SUN LDAP server

At work we decid­ed to update our LDAP infra­struc­ture. From SUN Direc­to­ry Serv­er 5.2 to 6.3(.1). The per­son doing this is: me.

We have some require­ments for the appli­ca­tions we install, we want them in spe­cif­ic loca­tions so that we are able to move them between servers more eas­i­ly (no need to search all stuff in the entire sys­tem, just the gener­ic loca­tion and some stuff in /etc needs to be tak­en care of… in the best case). SUN offers the DSEE 6.3.1 as a pack­age or as a ZIP-distribution. I decid­ed to down­load the ZIP-distribution, as this implies less stuff in non-conforming places.

The instal­la­tion went OK. After the ini­tial hur­dles of search­ing the SMF man­i­fest ref­er­enced in the docs (a com­mand shall install it) but not find­ing them because the ZIP-distribution does not con­tain this func­tion­al­i­ty (I see no tech­ni­cal rea­son; I installed the man­i­fest by hand), I had the new serv­er up, the data import­ed, and a work­sta­tion con­fig­ured to use this new server.

The next step was to set­up a sec­ond serv­er for multi-master repli­ca­tion. The docs for DSEE tell to use the web inter­face to con­fig­ure the repli­ca­tion (this is pre­ferred over the com­mand line way). I am more a com­mand line guy, but OK, if it is that much rec­om­mend­ed, I decid­ed to give it a try… and the web inter­face had to be installed any­way, so that the less com­mand line affine peo­ple in our team can have a look in case it is needed.

The bad news, it was hard to get the webin­ter­face up and run­ning. In the pack­age dis­tri­b­u­tion all this is sup­posed to be very easy, but in the ZIP-distribution I stum­bled over a lot of hur­dles. The GUI had to be installed in the java appli­ca­tion serv­er by hand instead of the more auto­mat­ic way when installed as a pack­age. When fol­low­ing the instal­la­tion pro­ce­dure, the appli­ca­tion serv­er wants a pass­word to start the web inter­face. The pack­age ver­sion allows to reg­is­ter it in the solaris man­age­ment inter­face, the ZIP-distribution does not (direct access to it works, off course). Adding a serv­er to the direc­to­ry serv­er web inter­face does not work via the web inter­face, I had to reg­is­ter it on the com­mand line. Once it is reg­is­tered, not every­thing of the LDAP serv­er is acces­si­ble, e.g. the error mes­sages and sim­i­lar. This may or may not be relat­ed to the fact that it is not very clear which programs/daemons/services have to run, for exam­ple do I need to use the cacaoadm of the sys­tem, or the one which comes with DSEE? In my tests it looks like they are dif­fer­ent beasts inde­pen­dent from each oth­er, but I did not try all pos­si­ble com­bi­na­tions to see if this affects the behav­ior of the web inter­face or not.

All the prob­lems may be doc­u­ment­ed in one or two of the DSEE doc­u­ments, but at least in the instal­la­tion doc­u­ment there is not enough doc­u­men­ta­tion regard­ing all my ques­tions. Seems I have to read a lot more doc­u­men­ta­tion to get the web inter­face run­ning… which is a shame, as the man­age­ment inter­face which is sup­posed to make the admin­is­tra­tion more easy needs more doc­u­men­ta­tion than the prod­uct it is sup­posed to manage.

Oh, yes, once I had both LDAP servers reg­is­tered in the web inter­face, set­ting up the repli­ca­tion was very easy.

Test­ing tarsnap

I am impressed. Yes, real­ly. It seems tarsnap DTRT.

I made a test with tarsnap. I made a back­up of some data (a full back­up of every­thing is kept on a ZFS vol­ume on an exter­nal disk which is only attached to make a full back­up once in a while) of one of my sys­tems. This data is 1.1 GB in size (most of it is /usr/src checked out via sub­ver­sion and extend­ed with some patch­es – no music, pic­tures or oth­er such data). This com­press­es down to 325 MB. Of this 325 MB of data only 242 MB is stored encrypt­ed on the tarsnap serv­er (auto­mat­ic de-duplication on the back­up client). The sec­ond back­up of the same data in the fol­low­ing night (again 1.1 GB in total, 325 MB com­pressed) caused 216 kB of new data to be stored on the tarsnap serv­er (again, de-duplication on the client). What I have now are two full off-site back­ups of this data (two archives with 1.1 GB of data after decom­pres­sion), with the ben­e­fit that the addi­tion­al stor­age space required is the stor­age space of an incre­men­tal backup.

The cost (in dol­lar) of this so far is 0.074603634 for the ini­tial trans­fer of the data, 0.00242067783 for the data stor­age on the first day, plus 0.0019572486 for the trans­fer for the sec­ond back­up. From the ini­tial 29.93 I still have 29.85 (round­ed) left. If I fac­tor out the ini­tial trans­fer and assum­ing that the rate of change for this sys­tem stays con­stant, this comes down to 0.01 (rounded-up) per day for this sys­tem (or about 8 years of back­up if I do not add more sys­tems and do not add more than the ini­tial 29.93 (= EUR 20) – and the price of this ser­vice does not increase, off course). Is this data worth 1 cent per day for me? Yes, for sure! Even more, but hey, you did not read this here. 🙂

That is what you get when a per­son designs a ser­vice which he is will­ing to use him­self for a price he wants to pay him­self (while still not lose mon­ey with the service).

Col­in, again, I am impressed. Big thumbs up for you!

Now I just have to add some more sys­tems (/etc and sim­i­lar of var­i­ous jails… and of course the data of this blog) and pol­ish my tarsnap script for “peri­od­ic daily” .

P.S.: Yes there are also places to improve, I found already some things (the con­fig file pars­er is a lit­tle bit strict what it accepts, and some things should be more doc­u­ment­ed) but Col­in is respon­sive and open to improve­ment suggestions.

Local back­up vs. tarsnap

A lot of peo­ple do not do back­ups at home. Unfor­tu­nate­ly this includes me. So far I was lucky that noth­ing bad hap­pened (or that I was able to get back all via manip­u­lat­ing on-disk-data by hand). For me this is most­ly because of the price and com­plex­i­ty (num­ber of back­up media involved) for local back­ups. It also means that I only need a back­up for the case of a disk-crash, not because I need to recov­er a file because I acci­dent­ly delet­ed it (yes, I am very good at not loos­ing data at home… maybe this is also the rea­son why I have so much data).

I have about 1 TB of raw disk space at home (two times raidz1). Not all of this needs a back­up (or is used at all), for exam­ple the base sys­tem files, /usr/local, the ports dis­t­files and pack­ages all do not need a back­up, but my cam­era fotos (cur­rent­ly 8 GB) should be includ­ed in a back­up, my home should be includ­ed in a back­up, my local stag­ing area for the con­tent of my web­serv­er should be includ­ed in a back­up, my mails (cur­rent­ly 800 MB) should be includ­ed in the back­up, local patch­es to FreeB­SD should be includ­ed in the backup, …

So let us cal­cu­late with about 200 GB of more (mails, fotos, pri­vate videos) or less (MP3s from my own CDs) impor­tant data for a full back­up. Most of it will not change often (MP3s, pri­vate videos, fotos), so once a month should be ok, and some (e.g. my mails) change dai­ly, so an incre­men­tal each day and a full once a week would be inter­est­ing for me. When I do such a back­up, I do not want to shuf­fle around tapes a lot. Maybe one or two times (s0 2 – 3 tapes) would be ok. So I am talk­ing about 80 – 200 GB per tape. The prices for this range from 700 EUR to 1300 EUR just for the tape dri­ve. I have also seen a tape dri­ve from Iomega for about 400 EUR (120 GB per tape), but some­how this sounds like a not so trust­worty solu­tion to me (I do not know why, it is just a feel­ing, maybe I am a lit­tle bit biased because of the high-end solu­tion at work, if some­one knows more about those Iomega dri­ves and tapes in a long term or high-useage envi­ron­ment, please write a comment).

When I take the cur­rent price of tarsnap into account, I come to about $60 per month for the stor­age, and again $60 for the ini­tial trans­fer of 200 GB. This assumes the 200 GB are not very com­press­able. With each incre­men­tal back­up (changed files mat­ter, not a diff between the files), I assume about 10 GB per month of change (= $3 per month). Yes, this is most prob­a­bly too much, but I try to cal­cu­late a worst case sce­nario. So this sums up to $60 once and $63 per month. I do not take into account my too slow upstream band­with. When I assume a 1500 EUR tape dri­ve plus tapes plus clean­ing car­tridge, we are talk­ing about some­thing like 2 – 3 years of stor­ing the back­up in tarsnap (with the Iomega dri­ve this would be just one year).

When I assume that I over­es­ti­mat­ed every­thing with a fac­tor of 2, this means 5 – 6 years of using tarsnap vs. buy­ing an expen­sive tape dri­ve. Now the ques­tion is, will the tape dri­ve sur­vive this long, will I be able to use such a dri­ve in new hard­ware  in 6 years, will tarsnap sur­vive this long, and will it stay at the same or bet­ter price lev­el (this is also influ­enced by the price of the stor­age provider).

Anoth­er solu­tion would be to go with a mixed set­ting, e.g. an 1 TB hard-disk (less than 150 EUR  for the hard-disk (with 7 years war­ran­ty) and an exter­nal case) to do the long term stor­age of high-volume but long-term-stable stuff (fotos, videos, music), and use tarsnap for the low-volume fast chang­ing stuff (con­fig files, mails). This way the amount of mon­ey for the real­ly impor­tant things is not much, I would expect less than 1 GB com­pressed (= less than an EUR per month). This also sounds like a solu­tion which allows me to be lazy (the impor­tant stuff can be auto­mat­ed, the nice to have stuff can be done from time to time as needed).

I think I should ask Collin if he has a way to receive SWIFT (IBAN/BIC) trans­fers for tarsnap…