Equallogic Arrays is NetBSD based?
I had a WebEX session with US Equallogic Support yesterday, I saw the followings when he had direct access to EQL PS6000XV console.
cli-child-3.2# uname -a
NetBSD 1.6.2 NetBSD 1.6.2 (EQL.PSS)
Also during the booting process of PS6000XV, the active controller module shows 4 cores
All slave cpus (16) ack’ed userapp init
count = 4, total =4
All slave cpus (4) ack’ed message ring init
For a list of undocumented Equallogic CLI commands, see this link.
I was also told the CPU of PS4000 series is dual-cores, that’s why it’s slower than PS6000 series in terms of performance.
Yes, it is NetBSD Linux.
I got a equallogic emulator (a PS6000XV with 16 disc) from EQ training last, it can run on VM desktop.
Oh…to my understanding, I thought there is no Equallogic emulator available, this is definitely eye opening. So what does it do? Is it just a Group Manager GUI with SANHQ?
BTW, I was told on the EQ training course, if there are two controllers in a EQ box, the stand by controller is not in idle mode, it will ’share’ some task from the primary controller, reduce the loading of the primary controller.
No, the emulator is a full function EQ box, running on a vm desktop, and then you are access / handle this box as normal PS unit.
Equallogic dual controllers are Active-Passive, so the standby (passive) controller remain idle for sure, sometimes Xia Men EQL staff tends to give wrong information.
Other SAN such as Hitachi HDS is Active-Active, they both have their pros and cons.
You can login as user root with the grpmanager password. Keep in mind it is unsupported by far. You can do several commands like raidinfo or diskview.
FYI: NetBSD is not Linux and the OS that the array loads to get started is NetBSD. However, the EQL code written in house does all the real work. Including handling all the network and iSCSI processes. So for management (SSH/FTP/WEB) you’re accessing NetBSD. It will then communicate with the EQL code. Much like the console on a switch, that OS isn’t what does the real work. It’s the code written into the ASICs.
Also, be VERY, VERY, VERY careful when at the root prompt. There are no protections against destroying data like there is on the CLI or GUI. I would strongly suggest not playing around at that level w/o direct input from support. As things change with firmware revs it could have a different result. And that’s not documented anywhere. There’s one command for example that if you use an certain upper case letter as a parameter will cause a CM failover. Not harmful, but not something you want to happen w/o warning. It’s also possible to irrevocably destroy your data. If part of a multi-member pool you’ll end up having to restore from backup/replication.