<cross post from java.net>

Sun Grid looks like a traditional IT stack, exposing common interfaces to enable developers and ISV's to target different abstraction layers:

The core environment is made up of a “Resource Factory” (RF), a production plant that is optimized to produce power at appropriately consumable chunks (balancing the economics of operations/distribution against typically demanded performance units). In this model the resources are managed by a Distributed Resource Manager and similarly metered/monitored using commercial DRM's and OSS/J technologies through a Service Data Record (a superset of the traditional telco model of a CDR or Call Data Record). Over time, Sun Grid will allow for multiple/pluggable Distributed Resource Managers through the support of a super scheduler which will allow a variety of resource management models to be deployed to support the various container/containment strategies for managed workloads.

Where the RF and it's blueprints are probably interesting to Data Center operators/managers who themselves are embarking on virtualization and distributed resource control/managment projects, the developers will probably not have a lot of use for this abstraction. IMO, what developers are really looking for is a set of runtime containers that are as thick/thin, complete or pluggable as their applications demand. This means that we need a container model that allows for specific orchestration.

For example, in a traditional 3-tiered (I know, nothing is traditional anymore) architecture, the separation of concern drives us to the isolation of the MVC across multiple tiers.... this means that we need a content delivery/presentation container, and a business logic container which is suitably aligned with it's data management containers/services. How do we describe these relationships in both functional and non-functional ways? Right now this is more art, than science which is to say that there are a number of different mechanisms, each with specific value propositions, and each with their own warts. Sun has the N1 Service Provisioning System (SPS), we also have DCML (an OASIS activity), WS-Management, and even techniques from the GGF which are trying to expose enterprise services using declarative markups.

This blog is getting a bit long, so I'll follow up in a second, but let me not leave without talking about the REAL value proposition for developers (the higher layers), here are some of the services that I'm thinking about:

• a repository for open source components and libraries allowing for both forward, and regression testing that developers can use, without distribution licensing concerns (caveat emptor) to build, test, re-factor, test new version... their service / application
• a repository, a vending machine really, for commercial components that can be used in a metered/rated way (see OSS/J note above) by other developers to shorten time to deployment, improve competitive comparison, open up new opportunities and markets, and allow components to compete in an open capital market/exchange (is my component really $xx better per use than yours... if it is then I'm incented to keep developing).
• a service facade for public/private hosted services that build on the economics of the Sun Grid and the pay-as-you-use model, as well as providing improved integration through close proximity to other's services (proximity remains very important in reducing latency in distributed service based architectures).
• common services, including things like federated identity and common entitlement policies that allow these ecosystems to emerge.
• a piloting ground for commercial software... instead of shipping a disk, why not take a SaaS approach where a demonstration entitlement is granted and instantly provisioned... how much could we reduce the cost of software sale.
• and finally, but not least, produce a mechanism, like the component/service mechanisms above to allow for business processes to be patterned, shared, extended and sold to perform regulatory or other tasks. Things that haven't yet emerged in the open communities, but are certain to once suitable service oriented substrates are available.

I hope that I've been able to elucidate some of the value that a common utility could provide, and facilitate through the Java.NET community as we move forward on this journey.

Please join us in the Sun Grid Community, sign up a new project, get some free grid time, and let's move this vision forward.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/the_sun_grid_environment_the

Depending on who you talk to, computing is a competitive weapon or a cost of doing business, either way it's an investment. One question that each and every new project has as it moves from the business plan to implementation is the often excessive cost and time to put into place the infrastructure so that you can finally realize that killer application.

With the advent of utility computing, and before that, outsourcing, businesses gained the ability to shift the costs from capital costs to expenses, and in doing so have improved their capital portfolio and cash flow positions. Now you have a new initiative, and though you have models/projections wrt. the data transfer, loading, processing and storage rates, you are probably still not quite certain of how this should be architected. One potential BluePrint comes from Sun in it's Sun Grid Rack System and Sun Grid Utility Services approach. This blueprint gives you the ability to take industry standard x64 servers or the novel SPARC CoolThread (Niagra T1) based systems to grow your computing plant just in time, in small incremental grains with incremental cost ( the value engineering done by the core utility team).

Take advantage of package density, operational automation, systemic monitoring and metering and workload scheduling advancements that are currently under investigation by the Sun Grid team as your solution matures. Furthermore, this puts you under initial control of your near term deliverables (your hw, your sw, onsite) and aligns with options for fiscal improvements/flexibility in longer term. If your initiative is radically successful to the business, you look to “join” Sun Grid, allowing your work to be distributed onto the Sun Grid mesh of data centers in addition to your own; this gives both time to market, peak scale as well as geographic diversity for high availability.

How do we get started?

1. Let's talk about the blueprinting - will your application fit this design... horizontal computing services are different from vertically integrated services in their treatment of memory (the largest issue) specifically the unified memory architecture of SMP machines is a critical facilitator to some large scale transactional systems.
2. If we can go horizontal - which most if not all new applications (green field) can, then let's think about the data flow to look at the points of constriction. Areas where we become hardware limited because of disk, network and cpu speed/contention.
3. With these “critical to scale points” in mind, let's determine a scalability strategy to help us parse this load coherently and with availability. Many of todays applications are well suited for pipelined approaches as in the image here.
4. determine the core services that need to be shared, and how these core services can be federated benefiting both your company and your partners - federation is about the sharing of responsibility and control.
5. go back to 2, and continue to refactor until scalability can be addressed with some fudge factor that lends the software developers some flexibility in approach.

We are ready when you are with a set of System Integrator Partners, ISV's, Client Solutions team, and a very active Open Community to help you take advantage of these emerging models, simplifying your Data Center, and changing the economics of corporate and research computing.

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/so_you_have_a_new

We have seen numerous press releases on Message Passing Interfaces (MPI) lately including those from Microsoft who has been working with Argonne Labs (funding a Win32 port) of MPICH2, and this, most recent announcement of Ohio State University's port of MVAPICH to Solaris across Infiniband.

Sun has been collaborating with OSU for a long time, working with Linux and Solaris on both SPARC and x64 based platforms. The current announcement from OSU is a novel MPI-2 based design (at the ADI-3 level) providing uDAPL-Solairs support. So what is this acronym soup?

Infiniband: a high performance switched fabric providing high bandwidth (in excess of 30Gbps) and low latency (can be lower than (<)5ms for serial I/O (channel based) between two host channel adapters (HCAs which are available at costs < $70). This fabric utilizes a separate I/O | communications processor from the traditional node CPU to allow the independent scaling of I/O and the offloading of I/O responsibilities allowing performance & cost tuning of computing clusters. Typical per port costs are in the $300 range (HCA & TCA) vs. >$1k for 10GBE adapters, so performance@cost is definitely in IB's favor for the highest of performance needs.

Message Passing Interface (MPI): established in 1999 to provide a standard set of message passing routines that focus on both performance and portability, recognizing that these goals are often at odds with one another. MPI-2 work was begun in 1997 was designed to realize areas where the MPI forum was initially unable to reach consensus like one-sided communications & file I/O. Basically MPI, makes use of GETting or PUTting ( or ACCUMULATE) data from/to a remote window that reflects a shared memory space in non-blocking ways for parallelized performance (an older, but still relevant tutorial from University of Edinburgh).

User-Level Direct Access Transport APIs (uDAPL): there has been a need to standardize a set of user-level API's across a variety of RDMA capable transports such as InfiniBand (IB), VI and RDDP. The model, is a familiar one to most infrastructure programers, that of a interface producer (both local and remote) and an interface consumer that has visibility as to the localness of the provider. uDAPL is designed to be agnostic to transport ala IB to unlock consumers (like MPI) from the intricacies of the underlying transport in a standardized way. Within this layer cake, it is expected that a uDAPL consumer will talk across a fabric to another uDAPL consumer though this is not mandated, it is common practice.

MPICH & MVAPICH2: are implementations of MPI provided by a variety of entities (mostly government agencies/labs and universities) which are frequently competed on features and performance. MVAPICH2 has been focused on IB, whereas MPICH2 supports other interconnects including Quadratics and Myrinet, either way, the goal is to create a high performance consumer (programmer) interface that can sit on standard or customized interconnection stacks. Where MVAPICH2 tends to shine is in larger packets providing higher bandwidth (though at a cost to small packet latency). A reasonable comparison from OSU and Dr Panda here (though we have to remember Dr. Panda's sponsorship of MVAPICH).

So that was a short summary, but hopefully this just wets your appetite for looking at architectures like Infiniband for constructing highly performant Grids/Clusters, and some of the techniques that you might request from Sun Grid to accelerate your parallel applications.

BTW: Sun Grid has MPICH 1.2.6 pre-installed including Java wrappers, here is a sample deployment script:

Permalink
Trackback: http://blogs.sun.com/dhushon/entry/p_we_have_seen_numerous