menu
Mar 2006
Last Weekend was a bit filled up with experiments since I run out of time until I will return the T2000. I didn’t really count how often I reinstalled the T2000, only that I did install various versions of Solaris and Nevada and tried to put Ubuntu in a zone. Just to mention that at first: I failed with Ubuntu and ran into diverse configuration- and problemloops. So I just quit the Ubuntu experiment. I would have wanted to have some sparc-linux zones on the machine for another introsession at the university this week. But, no time left. That reminds me that I have to plan for some kind of lab-setup for this summer’s administrationcourse on Solaris for Students at the FU Berlin that I am asked to run. Could be that I reuse my 8 old U60ies for that. Of course a T2000 with LDoms and SunRay on it would be great. If I then could find someone lending me those Tadpole “Notebook-SunRays” that would be even better, it would be a killer-labsetup put in place in 10 Minutes!
Something new happened, I installed Nevada build 54 on the T2000. Upon reboot of the machine I got:
svc:/platform/sun4v/efdaemon:default (embedded FCode interpreter)
State: maintenance since January 6, 2007 10:23:35 PM MET
Reason: Start method failed repeatedly, last exited with status 1.
See: http://sun.com/msg/SMF-8000-KS
See: man -M /usr/share/man -s 1M efdaemon
See: /var/svc/log/platform-sun4v-efdaemon:default.log
Impact: This service is not running.
I did not find anything reasonable why the efdaemon could not be started.
Well so. It was zones I played around. Not special to the machine so, but I do not have much free compute capacity to do so. In the Book on OpenSolaris I mentioned a mechanism to setup ftp/web-servers in zones that could automatically be removed and reinstalled when contaminated by an intruder. ZFS lead me to another idea: Setup zones in ZFS filesystems, a filesystem per zone in one pool. Make a snapshot of the zones filesystems. If a zone then becomes contaminated by an intruder, simply stop the zone, do a ZFS-rollback of the zones filesystem and restart the zone. My main question was on how fast this rollback-restart can be. But since I do not care about an ordered shutdown of a zone that is contaminated I decided that I can do the rollback underneath the running zone initiated out of the global zone of cause and do the zone-reboot simultaniusly. This did work, so it just took the zone reboot-time. I guess I will rewrite this chapter in my book. This reminds me that I should save some of my logs to put some examples in my book’s second release this year for the existing chapter on consolidation.
Next thing to test was clustered zones with the now released GA-version of SunCluster 3.2. Since I do not have PCI-X fcal-boards to put in the T2000, I decided to put the T2000 as a storageless node into the cluster and hope that two gigabit interfaces in the private net is aceptable for the PxFS-I/O that will arise. I planned to cluster zones of the T2000 against the global zone of one of my 280Rs, e.g. if a zone is to fail over to one of the 280Rs, it will not be the whole zone but the resourcegroups in that zone. But a little Graphic shows that better:
Well this is what I planned. Reality looked a bit different: It didn’t work that way. So it is not specified in the manuals, I know, but why shouldn’t I give that a try:}
Next idea was to do this rollback-zone-restart by an agent in the cluster and have the agent snooping in the zone to check if it still trustable. This is quite another idea of an agent: The agent checks not if the zone is running or has to fail over, it checks a zone’s integrity, if it is contaminated by an intruder. If so the agent will initiate a restart procedure for the zone in question. Simple idea. The rest of the evening went into writing the agent. Some of my best pitfalls:
Rollback of the zfs underneath most parts of the OS and clustersoftware in the global zone, not only the local zone. The machine looked great after that! I had won a reinstallation with that simple error of mine:{
I even did this error three times! Guess it was too late in the evening:{{
The last reinstallation I did on Monday noon I decided to restrict usage of zfs to the direcory where I put the zones. But still the idea of a clusteragent restarting a zone in case it gets contaminated, drives me somehow. It allows for a different kind of failover reasons and allows a different kind of HA. A zone will fail over if it crashes and will simply rollback/restart if it is contaminated or both. So now I was investigating on what to check to determine a zone’s integrity. Checksums on files in a zone’s filesystem? What about in-core objects. What about loaded -fake-drivers. I remember a presentation on the Solaris securityframework by some sunny that was very interesting. I must have the pdf somewhere (still digging for it, filesystems get larger these days:( What I do for now is filesystem-based checksumming and diffing the cleaned and sorted ps-output to that of the zones startup processes. It is a beginning, there is some…..work open on that….
So right now a reinstallation of the T2000 is running for the solaris introsession that I run on wednesday. This time I keep the second disk with my clusterinstallation at home in order to be able to continue with the clusteragent as easy as possible. By the way I hope the T2000 doesn’t really care if the second harddisk is not in while running a day in a classroom. But the disk/DVD/powersupply bay is seperate from the CPU/IO-board bay so I assume it will not have any effects on the CPU. By the way, Sun could offer a 1U ups in the same design as the T2000. That idea came to me the last time I was out with the T2000 because I am always asked about that ugly little beige deskside box I carry with me: It is my UPS to go. I don’t want to risk the T2000s powersupplys in case of voltagedrops. Another great thing would be the option to replace a powersupply with a batterypack, to provide buffered voltage to the beast - For fairs and external presentations, that would be quite a relief.
I’m still on hold if I can get access to LDoms. If they’re anything like I imagine them to be according to what I could gleam from the documentation, they’re a killer configuration for this beast.
With an IBM iSeries/pSeris, a customer needs a HMC (separate linux-based PC) if he wants to configure more than two LPAR partitions. This dependency just doesn’t exist with LDoms. It’d be great if the virtual consoles that are presented by the hypervisor and can be addressed by that software terminalconcentrator and could be addressed the same way it is already done in the SF68000. There, the hardware domains can be referenced directly by addressing the system controller and the appropriate port number for the domain.
It also would be a great extension to alom-based machines if the solaris console could be addressed by telnet/port number through the alom controller. You then just have to type “telnet rsc-ip port” to get the domain’s solaris console.