Inchoate Curmudgeon

The large array of Sun platform choices for modernizing older SPARC implementations has a consequence: discerning the correct path, based on your particular situation. There are pros and cons to every approach. For many operations, the most difficult fork in the decision tree is deciding between Sun CoolThreads (CMT) and SPARC 64 architectures versus Sun platforms with x86/x64 processor architectures. This is particularly true for enterprises with existing Linux x86 implementations on competitor platforms facing technology upgrades of aging SPARC infrastructures.

This is a revision of a brief Sun put together for a customer as part of a consolidation workshop. Note: my colleagues Teresa Major, Christine Tran, Cecil Jacobs and Matt Fifer all contributed to the original brief.

Although this analysis presents a strong bias toward SPARC, the point is to provide points of reference for a reasoned discussion for enterprises making strategic decisions around large-scale processor architecture decisions related to consolidation and optimization. I love my x4100 and my Intel Mac, but there are larger, serious considerations in play when dealing with estates of hundreds or thousands of servers, strategic IT decisions and large, enterprise workloads.

1. Deployment of compiled applications from SPARC to CMT and SPARC64 is a simple migration, re-deployment from SPARC to x86 requires more complicated steps such as re-compilation. For customers re-deploying from SPARC Solaris to Solaris x86, the Sun Source Code Compatibility Guarantee significantly reduces the risks of changing platforms to Solaris x86 versus full porting to other operating systems such as Linux. However, there are still risks presented by migration from SPARC to x86/x64 architectures versus simple platform change to a more modern version of the same SPARC T1 processor architecture.
1. Data migration must account for byte ordering and byte alignment differences between the x86 and SPARC processor architectures.
2. Re-compilation will require source code, which may not always be readily available or known to match the current deployment.
3. Dependencies on all third party SPARC libraries and tools must be satisfied by equivalent x86 libraries that may be difficult to acquire or may not be available in the older, currently deployed versions.
   

The impacts from re-compilation requirements for transition from SPARC to x86/x64 may even exist at some level for architecture-independent J2EE and Java implementations, since many organizations include the practice of re-compiling applications as a preliminary step to production deployment. This at least implies adjustments to the pre-production build processes and configurations as part of a processor architecture change.

2. The Niagara uses 72W and provides 32 threads (virtual CPUs) per socket. It can do the same work as an x86/x64 architecture machine for less power. The same advantage of newer CMT designs over x86/x64 processors will persist for the foreseeable future. However, this general advantage of the CMT architecture efficiency can’t substitute for empirical workload characterization against various processor choices for the best choice; the power use of a system is extremely sensitive to the workload. Parenthetically, any organization with data center power and space constraints, which is almost every one I see, should be including CoolThreads machines in its evaluations. If there is any single factor most likely to influence structural changes to an enterprise’s processor architecture strategy, it is the serious and growing issue of power efficiency.
3. Solaris has excellent ISV support. Solaris on SPARC has over 4300 applications shipping as of October 12. While ISV enthusiasm Solaris on x86/x64 is growing, there were about 2600 applications for x86/x64 shipping as of October 12.
4. SPARC systems have greater RAS (Reliability, Availability, Serviceability) than X64 systems with features such as ASR (Automatic System Recovery) and predictive self-healing. Sun x64 systems have many innovations that implement higher RAS characteristics than similar, competitive x64 products, such as hot-swappable and redundant hard disk drives (when RAID is used), fans, hot-swappable and redundant power supplies, and hot-swappable I/O cards and components available in the x64 blade servers, particularly when running Solaris x86, but these capabilities lag overall SPARC systems RAS characteristics and features in all product lines.
5. CMT and SPARC64 run several Linux variants, including Ubuntu and Gentoo, diluting the value proposition of alternate open source UNIX variant availability for x86/x64 platforms versus SPARC.
6. The CMT servers support Logical Domains (LDOM), which allow for simple server micro-partitioning of CPU and memory resources. SPARC64 platforms support Dynamic System Domains (DSD), which allow for socket partitioning of machines. There are no x86/x64 platforms with a similar capability.
7. Logical Domains (LDOM) and SPARC64 Dynamic System Domains (DSD) provide a greater degree of isolation between OS environments than Solaris Containers, xVM, Xen or VMware virtual machines. LDOMs are only available on Sun CMT processor architectures. Dynamic Domains are only available on Sun-Fujitsu SPARC64 platforms. This virtualization strategy decision point revolves around a stress between isolation, efficiency and utilization: it is generally simpler to leverage excess capacity with Solaris Containers, xVM or VMware vs. LDOMs. However, it is generally simpler to implement, manage and operate statically defined LDOM and DSD resource pools. LDOM and Dynamic Domain availability may be a stronger factor in the decision making process for operations attempting to virtualize and consolidate multi-processor, one-machine, one-application services and workloads, since the simple application of static, fixed resources to an application or service using LDOM or DSD may out-weigh the business and operational implications of the efficient sharing of resources between business units using Solaris Containers, xVM, Xen, VMware or other similar technologies. CMT and DSD capable processors represent the greatest possible flexibility and the deployment architecture can leverage the full complement of virtualization methods: LDOMs or DSDs and Solaris Containers, as appropriate.
8. The vitality of the SPARC roadmap versus various vendors x86/x64 plans is not a valid basis for comparison of the options. The SPARC lineup and robust roadmap is supported by a growing Sun Microsystems and a growing, vibrant developer community. SPARC has a well defined, published, and committed roadmap of innovation that extends well beyond 2011. This roadmap includes:
   • the sun4u SPARC64 processor and SPARC Enterprise line from Sun-Fujitsu,
     
   • the sun4v T1, T2, multisocket T2 (”Victoria Falls”) from Sun, and
     
   • the sun4v ROCK processors from Sun.
9. The complete range of scaling choices for SPARC and CMT is unmatched in x86/x64 implementations. The recent announcement of 64 thread implementations reinforces this growing advantage of SPARC over x86/x64. The current and future product lines based on the SPARC instruction set range from single socket systems to multi-socket, massively scalable systems with over a terabyte of RAM and hundreds of execution threads, all of which can run any application supported on SPARC. This range of vertical and horizontal scaling options may be a factor for organizations that have both types of application workloads that wish to limit the proliferation of processor architectures in deployment as much as possible.
10. The sun4v architecture provides the mechanism for presenting an abstraction of the hardware layer to the Solaris operating environment, making it much easier to deploy new hardware platforms based on sun4v while continuing to use the same version of the Solaris OS for extended periods of time. This reduces the risk of having to do another migration in the future just to take advantage of newer, faster hardware.
11. Sun’s commitment to open source across all parts of it’s business and product offerings includes the processor design for the UltraSPARC T1. This has already resulted in a binary compatible third-party embedded solution.

Trackback URI | Comments RSS