The Sun Fire T1000 from Sun is a 1U rack mount server incorporating the T1 Niagara SPARC CPU. Out of the box, the test unit came with a rack mount kit, two network cables, and a serial adapter for the management port, one eight-core T1 CPU, 16 GB of RAM, one 80 GB SATA hard drive, and four Gigabit Ethernet ports. The power cord was missing, although Sun assured me that production units do come with a power cord and this was an oversight on its part.
The unit has Solaris 10 loaded in a "fresh installation" condition. Internally, there is one hard drive bay and only one internal SATA connector on the motherboard. Soon to be released units will be offered with two 2.5" SAS drives. There are no monitor, keyboard, mouse, or USB connectors on the T1000. It consumes relatively little power, with an average operating consumption of 180 watts, as reported by Sun.
Physically, the T1000 meets all expectations. The case is typical for a 1U rack mount server. I had some difficulty removing the top cover on the test unit, a minor design flaw that Sun states was typical in early units and has since been remedied. A set of full instructions for common maintenance and upgrade tasks has been put onto a label directly on top of the unit, which is helpful.
One problem with the unit's physical design is that any maintenance requires the cover to be opened. Neither the hard drive nor the power supply can be removed without the cover being removed, so even the most common break/fix tasks require the unit to be removed from the rack. Given the number of wires that can be connected to the T1000 (management cable, power cable, and up to four network cables), this is a good deal more hassle than some system administrators, particularly those accustomed to blade units, may be accustomed to.
The T1 CPU
Although Sun has open sourced the T1 design, it's currently the only company producing servers with this CPU. The T1 is a multicore processor (currently offered in six- and eight-core variations) utilizing Sun's CoolThreads technology. CoolThreads allows the CPU to consume very little power, while at the same time allowing each core to simultaneously process four threads.
CoolThreads processes one thread and begins to compute the next thread while the first one waits on memory read/write. It does this for up to four threads per core, so at maximum capacity, each T1 may be processing up to 24 or 32 threads concurrently. Unfortunately, each core's single thread performance is a bit below par, which Sun confirmed. The T1 is currently running at 1.0 gHz, and even accounting for the typically lower clock speed of SPARC CPUs compared to x86 and x64 CPUs (the RISC architecture accomplishes more per clock cycle), it is still slower than its competition on a pure clock speed basis per thread.
Sun also assured me that it's working with major OSS projects, ISVs, and internally to port as many applications as possible to the T1 architecture, particularly to increase the use of multithreading to get maximum performance on the T1. Because the T1 CPU is a SPARC CPU, the T1000 (and other units using the T1 CPU) are not compatible with Windows or any other OS that's not compiled for the SPARC architecture.
The T1000 also uses Sun's ALOM (Advanced Lights Out Management) system to allow the administrator to perform basic management tasks regardless of the OS's status or whether the unit is powered on. Upon initial power-up, the unit took quite some time to start due to the in-depth testing that the ALOM performs on the CPU. Unless the unit loses or is disconnected from power, it will not need to perform these tests on subsequent reboots.
The ALOM is accessible via a serial port (an adapter comes with the unit; the cable used is a standard Cat5 or Cat6 cable, and the serial management port itself is an RJ45 jack), as well as through telnet. Sun informed me that there is a firmware upgrade that allows the ALOM to be accessed via SSH too, but it wasn't sure if this upgrade allows the telnet access to be disabled. Due to the powerful functions available in the ALOM, accessing the ALOM via telnet is a security risk.
The Solaris installation
Out of the box, the Solaris installation is not a good fit for this unit. Until Sun releases its "Secure by Default" version of Solaris (which will incorporate much of Trusted Solaris into the standard Solaris package; the remaining parts of Trusted Solaris will be sold as an add-on), system administrators will want to either reinstall Solaris from scratch or go through the arduous process of removing unwanted programs and disabling certain services. The default Solaris installation, for example, has Sendmail installed and turned on by default, which will allow this unit to be used as a spam relay the moment it is given a public IP address.
It also has GNOME, media players, and other desktop applications installed. Sun's response to this is that a "lowest common denominator" OS installation is not useful to anyone. However, I think that preloading a disabled OS and allowing system administrators to add and enable the applications and services that are needed is much more convenient than forcing an OS reinstallation from the get-go, and it's much safer than counting on the system administrator to find every unwanted application or service.
Because there are no internal or external drive or USB connectors, the only way to reinstall the operating system is over the network. To do so requires another computer on the network running Sun's Jumpstart software. As a result, you'll need to have a computer (or virtual machine) running Solaris or Linux to be used as a Jumpstart server. System administrators will want to make sure that this is tested and ready before an OS reinstall is required. Jumpstart supports only Solaris and Linux. The upcoming T1000+ will not support booting from a CD-ROM or DVD drive or an iSCSI target either.
Solaris 10 has many new advanced features. The new file system, ZFS,
promises fast, safe, and reliable data management. Solaris containers
chroot jails as a way of
sandboxing certain processes. Solaris 10 also introduces a new services architecture,
bringing traditional UNIX daemons to a new level. The services architecture
automatically handles dependencies as well as providing a standardized method
of starting, stopping, and restarting services. It is backward compatible with inetd and rc.d, and many standard
daemons have been ported to it.
Sun is working
with many major OSS
projects to port their programs to the services architecture. It
also has a great deal of experience with SMP and parallel processing services.
Solaris is generally regarded as an excellent OS for these types of
environments, which makes it a great fit for the T1 CPU. Solaris now also
supports "laced privileges," in which a process is granted root's access
levels, without actually becoming root, making it a more secure alternative to
sudo or running the process as root.
Solaris also supports "resource pods," which allow processes to run within virtual machines. These resource pods support prioritization and limitations of access to system resources. For example, a resource pod may be used to keep separate noncritical (or less time sensitive) operations from consuming resources that should be devoted to more important tasks.
Despite its advanced features, though, Solaris is an extremely difficult OS to work with, even compared to various Linux and BSD distributions. Upon the initial boot, I was led through a series of finalization steps, which were at times confusing. As a typical example, there were three language choices for the United States, with no hint as to which one was the best (or "standard" choice).
The package management system is quite rudimentary, comparable to FreeBSD's package system. Unlike FreeBSD (or any of the major OSS UNIXs) the package management system did not direct itself to fetch packages from a default Sun server, nor were any packages ready for installation. Installing any new software, therefore, requires manual downloading of the package and then installing it.
I had difficulties using the test unit with DHCP. The unit would not accept a hostname from the DHCP server (even with a reservation created), and manually setting the hostname in the unit's configuration would make Solaris believe that it was being assigned a static IP address and not use DHCP. Sun recognizes that both its Solaris installation system and package management systems are in dire need of a revamp, and it's working to address these issues. However, there is no date set for that to be completed, and Sun has traditionally not been very good at addressing the portion of the market that lacks Solaris expertise. Unfortunately for Sun, this segment is now the majority of UNIX system administrators, and more and more system administrators lack experience in UNIXs other than Linux. As Linux continues to become easier and easier to install and manage and becomes better suited for "big iron" applications, Solaris has to either catch up quickly or risk being further marginalized.
The T1000 has a built in hypervisor system that abstracts the hardware. Additionally, Sun is working with Xen to allow Solaris to be compatible with its hypervisor on non-Sun platforms. Some versions of Linux and BSD have already been ported to the T1 platform. However, the Jumpstart system for loading operating systems onto the unit is compatible only with Linux. Sun's hypervisor is supported only on the T1 and is not available on its AMD x64 systems.
Who should be looking at the T1000?
The T1000 is definitely not a unit for a company looking for just one consolidated server. To begin with, its storage capabilities demand that it have a NAS device or a SAN to connect to. Because it lacks any type of redundancy (single power supply, single hard drive), a simple failure can and will take the unit offline. It's also not very good for general purpose tasks, due to the poor single-threaded performance of the T1 CPU. Any application not written to be heavily multithreaded will run relatively slowly on the T1000.
To get the maximum benefit from the CoolThreads technology, this unit is best used as a Web or application server, especially one that handles many small or medium-size requests that perform a good amount of CPU time waiting on memory read/write. These types of applications will see significant performance gains. Sun also told me that Java programs run particularly well on this CPU, which is not surprising.
Ideally, the T1000 is used in high density data rooms. The insecurity of the ALOM network management system suggests that a serial port concentrator combined with the disconnection of the network management port is the best solution for handling this. The need for a SAN or NAS (and for more than one or two servers, SAN is really the best solution) implies the necessity for a large capital investment to gain maximum benefit from this unit. In some situations (such as many small, non-atomic, non-mission critical operations), the unit may be suitable by itself.
The difficulty of Solaris installation and maintenance makes it hard to justify having only one or two of these units on hand. Furthermore, the physical design makes it difficult to quickly repair a down unit. Combined with the lack of redundancy, this unit should not be used for mission-critical applications without a backup unit in place with fault tolerance or load balancing to ensure a smooth cutover in case of failure. Large enterprises will probably want to have a hard drive preloaded with their standard OS loadout to facilitate rapid fixes in case of drive failure.
Sun also has a system management utility, N1. This utility runs under Solaris and Linux. Sun seems to be committed to making its tools available on, and its systems compatible with, Linux—but not any other operating system, even non-Solaris or Linux UNIXs. This is an unfortunate trend. Many enterprises have a large amount of experience with other UNIXs, particularly various BSD distributions, and Sun is not putting any effort into helping them out. Indeed, FreeBSD was self-hosting on the T1 before any Linux was, but with the Jumpstart system, there is no easy way to get FreeBSD (or any other non-Linux or Solaris OS) onto a T1000.
Solaris' advanced features require a large knowledge base to use to them to their fullest potential and some time to properly configure. As a result, system administrators without the time to fully learn Solaris and its advanced functionality will not be able to take advantage of its features. If you have the time to learn how to configure these features. though, you will be able to tweak this unit to meet your needs much better than a typical Linux, BSD, or Windows server.
The Jumpstart system becomes much less of a liability (indeed, it becomes quite an advantage) once you have more than one or two units to manage. The ability to build a standard OS installation and rapidly deliver it to units really pays off in a dense environment but is probably too much effort for only one or two servers. It would be nice to be able to perform an OS installation outside the Jumpstart system, but Sun has no plans to address that at this time.
For small or medium-size businesses that want to have one server to handle all of their needs, Sun recommends the T2000. It also uses the T1 CPU but has much more storage capacity, as well as an optical drive to facilitate system maintenance and software installation. Given the relatively difficult nature of working with Solaris, a smaller IT shop would probably prefer to load a Linux onto one of these servers if it wants a generic "one box does all" server as opposed to an application server devoted to running a handful of highly multithreaded applications.
The T1000 is extremely price competitive with x86 and x64 systems in the same class. Add in its low power usage, and large enterprises—particularly those with existing Solaris experience and knowledge—would be wise to give the T1000 careful consideration. Similarly, organizations that currently have only one or two servers but that have expansion plans in the near future will want to consider beginning with a few T1000s. That way, they can rest assured that they will be able to rapidly build out and expand their data center in a cost-effective manner.
Smaller shops without any applications that require a particular UNIX will also want to consider making a switch to the T1000 now. They can start building up a library of Solaris installation images and gaining experience with the T1000 and Solaris today. Then, as their need for more advanced functionality increases, they'll be able to take advantage of Solaris' benefits instead of trying to retrofit their existing servers with that capability.
Justin James is the Lead Architect for Conigent.