We fully expect OpenSolaris to wind down over time (even with a fork) without explicit support from Oracle, so we don't want to start planning around OpenSolaris only to have to switch again. The path I'm investigating now is moving our mass storage platform to FreeBSD, and using the net/istgt iSCSI target and Samba to replace the ZFS share properties for those protocols. If that works in our torture testing with our controller cards, we're moving off of Solaris except for a lone server to test against the software we sell.
Oracle shut down all the over-the-web purchasing options for Solaris support contracts, re-directing everyone to their local reps. That pretty much screams, "unless you're talking a minimum of 4 figures and preferably 5, don't bother us".
We were willing to put in enough of an effort to adopt sufficient amounts of Solaris to have it manage all our spinning platters for us. We even had plans to integrate ZFS into our backup system (IBM TSM) so that we would automatically restore files from tape that ZFS indicated were damaged. But most of our work takes place on Linux (RHEL where required by the business application, and Ubuntu otherwise) and OS X, where frankly the hassle factor for maintaining an infrastructure component like an operating system is far less than Solaris (pre-Oracle, we had to wait nearly two weeks to get our support contract ID after purchasing it online). Sun hardware only made sense for us if we were planning on running compute services off of it, but Sun kept Solaris bottled up for so long that by the time we could try it out our infrastructure was already built up around Linux. Switching costs are too high for even ZFS to justify. If Oracle kept to the same support licensing terms however, I could see us gradually move over services one by one when it came time to migrate them to new hardware (which is when we usually evaluate whether it makes sense to switch OS platforms for the application).
I have enough on my hands that I don't need schizophrenic support licensing terms for basic infrastructure. Oracle has clearly signaled that unless you intend to make a major commitment to Solaris by willingly locking into their hardware and software NOW, they don't want your business, even if that timing doesn't fit with your business plans and planning horizons. If their support processes weren't stuck in the Stone Age, and the quality of patches weren't so sketchy that we found we must use Live Upgrade to protect ourselves, we probably would have shelled out. But Oracle jacked the premium for ZFS so high and so quickly they made the decision easy for us to start paying the money to test the alternatives.
We're drafting up backup plans to migrate our mass storage architecture off of ZFS and onto an ext4-based distributed filesystem on multiple nodes, in case FreeBSD doesn't work out. It will cost a bit less than what Oracle wants now, though it will still cost more than a basic support contract for a single Solaris server (pre-Oracle) spinning all the same spindles. We're hoping we can get by with FreeBSD 8.0/ZFS/istgt/smb for the next 4-5 years, and hopefully the situation between ZFS and btrfs under the same roof at Oracle is resolved by then.
At this point what's to tell Oracle that Solaris is better than Linux, because, I'm not sure they're convinced?
For my company, one acronym: ZFS. We're going to start clocking into petabytes of storage within a year, and right now we're handling the tens of terabytes of storage under Solaris with a basic support contract so I could pick up the patch updates and email with the odd, once-a-year problem I couldn't solve myself. I'm shudder to think of the supporting the same scale with any other filesystem; ZFS has seriously saved our asses several times now with just its scrubbing feature.
Oracle's new licensing policy has now put us into a bind. We now have to pick up Oracle Sun-branded hardware, plus the hardware support contract, plus the Oracle Premium software service plan. Then re-integrate the hardware with our existing configuration, possibly picking up new controller cards. Our carrying costs per year for choosing a Solaris-based solution just jumped an order of magnitude.
The only reason we haven't started planning a move to FreeBSD 8.x is because FreeBSD ZFS doesn't yet support iSCSI (because FreeBSD doesn't have an iSCSI target yet). ZFS just got hella more expensive.
Considering Apple's silent dropping of ZFS, I take it as a sign that in the future ZFS development will likely clam up to just Oracle Sun Solaris. Thus, we're going to follow Apple's lead and start testing ext4 under Linux (we first came to ZFS from ext3). I like ZFS, but not enough to justify a 10X cost difference unless there is simply no other way to hold petabytes off a single server.
IBM? Nobody buys P-series.
Um, since you claim to be from the big leagues, I want to offer a varying viewpoint. I don't know where you are getting your information from, but you might want to check your sources for more recent input. My large customers who use POWER-based System p and older pSeries systems are typically the large enterprises who want bulletproof virtualization (even better than VMWare ESX --- not ESXi, but the full-blooded ESX or even more feature-laden vSphere), and/or high bandwidth low latency I/O, or the IBM service network that materializes an engineer on your doorstep within a couple hours if you pay enough support, etc. Basically the kind of business where the downtime is measured starting at around $10K per minute and goes up rapidly from there to 7 figures, and need applications on a distributed system as opposed to a mainframe.
In the right hands, the gear works, and the OS (AIX), while it has its quirks like any other OS, is no slouch either. You can say that pretty much about the HP-UX and Solaris gear out there as well. That you even refer to it as "P-series" and don't even know how it was properly spelled shows that either you were sloppy (likely only because this is just Slashdot so who cares about the details, but if someone else was chronically like this they wouldn't likely fit in at my big System p accounts who are typically fussy and fastidious about even the nitpicking the details since so much is at stake), not up to date on this segment of the market, or perhaps not in the really big accounts who have looked at the alternatives to System p, and found them wanting in various aspects. It's a different world than most techies are used to, but I wouldn't dismiss it so casually if you want to make some good coin serving very demanding (but very well-funded) customers. There are even fewer customers buying System z, but I know some very wealthy IBM Business Partners and IBM coverage reps who serve the right accounts; you just have to know where to look to find people who need certain requirements filled and understand where more common solutions have a gap (I'm impatiently waiting for the OSS world to catch up in these gaps).
Your analysis on Oracle and Sun though, makes a lot of sense, you put it more concisely than I ever could have. Sun's flaking out on Solaris support is one reason why internally we're looking at migrating away to FreeBSD as the only reason we were using Solaris at all was for ZFS. It will be interesting to watch how Oracle digests that acquisition.
This action is likely continued fallout from the IBM-PSI lawsuit which ended in 2008 but has some reverberating ramifications. Page 36 of this z/Journal issue has a good overview of what happened. IBM now operates a PartnerWorld program where you can get a legitimate, IBM-sanctioned emulator for about $4K USD per year, expressly intended for just developers and OEMs who need a development platform but are not big enough to justify real System Z iron. This program comes with access to the ADCD that developers need to thoroughly test against different configurations. You can't sign up for this program if you only want to use it to knock points off of your annual hardware/software spend on mainframe iron, and IBM enforces this through their licensing and limitations on the emulators.
My guess is IBM has to do this to ensure another troll investor-funded PSI doesn't come out of the wood work looking for a buyout. Also, TurboHercules' legalistic business model of catering to disaster recovery situations was asking for trouble: the incremental revenue from DR where the vendor can sell hardware, software and support without incurring huge utilization of support and development staff, leading to giant margins compared to production environments, is precisely the kind of business that IBM wouldn't appreciate getting siphoned off. If TurboHercules had stuck to some zero-margin activity like free (or ridiculously cheap, about $1 a month) over-the-web education of mainframe skills, then provide value added training geared towards certification to make their real margins, and used real IBM iron to supply remote DR services while using the equipment when not supporting active DR to drive "pro" certification courses (with the understanding from customers of the courses that they could be kicked off if a DR incident demanded their space), then that might have worked, as it fills a niche (raising the next crop of mainframe users to system programmers) IBM currently spends money on today without any immediate returns.
I work all day in a programming language written by one of the biggest software companies in the world. The documentation is complete, detailed, and accurate.
What language and company is this?
Payrolls are hardly technically challenging. By way of perspective, 30 years ago I...
Perhaps you haven't been in the business since then? Payroll systems today for large organizations are very complex because they often have to deal with tax jurisdictions around the world, and tax regulations have become quite a lot more complex since you worked at that computer bureau. In the university's case, simply accommodating visiting faculty can be a challenge. Then there is all the change control that surrounds tracking ever-changing tax laws. We haven't even begun to discuss benefits calculations, which are always related to payroll systems as many benefits impact what is deducted from a paycheck. The only payroll processes that are simple these days are the ones for very small businesses with a single locale and static benefits package, like your basic mom and pop restaurant down the street at the corner. Pretty much everyone else has multiple tax jurisdictions to deal with, especially with globalization pressures compelling many companies to do business around the world to survive.
This is why payroll processing companies like ADP are so popular with businesses; doing even multi-state payroll in-house is not easy by any stretch of the imagination. Pro tip: choose your payroll processor carefully, as they can skip with your tax deposits, and as long as the amount is below the FBI threshhold for caring about white collar crime, they can disappear with your funds with no repercussions. And the tax agencies don't care some scumbag just stole your tax deposits. That industry is completely unregulated, and is a scammer's wet dream come true as it is the perfect crime; businesses scammed like this are so panicked dealing with the now-pissed tax agencies they rarely have time/manpower/willpower to pursue the payroll processor. Now imagine what happens when the payroll processing takes place outside the country; good luck pursuing them in court overseas.
I'm an IBM Business Partner, not an IBM'er, so I don't know how timely Blue Pages is. Your Blue Pages record will display your chain of command all the way up to Palmisano, but with all the re-orgs this year, I don't know if IBM keeps the records updated.
The re-orgs have really hurt IBM; a lot of sales efforts stall out with a re-org and it causes Business Partners like me to scramble trying to reignite those opportunities, and confuses customers where the sales reps leave in a hurry. Only about 10% of the sales reps I work with actually perform a thorough hand-off. IBM's numbers for 2009 and 2010 are not going to look good if this keeps up, because their sales momentum is taking a beating.
maxtorman, thank you very much for explaining the technical details. We just ordered two 20-drive cases of the 1TB ES.2 model ST31000340NS drives from Provantage on December 31, 2008 for a new server build. After this news hit TechReport.com, TomsHardware.com, Slashdot, and started to spread through the news aggregators like Reddit and Digg this week, we went to check if this model was affected by our choice of SAS controller, and indeed it was. We freaked out after going through the Seagate KB and support discussion forums, and this morning we were starting to consider returning all the drives unopened to Provantage and ordering Western Digital RE3 units instead, as the server build hadn't started yet.
Your patient description of the underlying technical issues and responses to others' questions in Slashdot gave us enough confidence to hold off until next week Friday before deciding whether or not to return the drives, based upon what we see happening in the 1.5TB drive firmware issue. Possibly longer, if Provantage will let us exchange for Western Digitals after a month of holding onto the case of unopened Seagates, should that prove necessary. At this point, we can't tell if the SAS controller issue we have identified is related to the 320th log entry issue you described, but they sound related, so one possible question for you is if you are aware of any relation between the issues. We plan a tremendous lot of slack into our server build projects, so we would rather have Seagate get it right with this next firmware release than try to push a release out just for appearance's sake. The data on these drives would be configured for software-based 3x-RAID1, and redundantly backed up to LTO4 tape as well, so a loss of a drive's data is not a concern for us. However, time spent rectifying an issue is a big deal, and while we are patient with issues before the server build, but once it is built and in production, issues like this have a very adverse operational impact upon us.
We are not a loved organization, but we are a respected one. -- John Fisher
