The NASDEV Architecture: How It All Fits Together

NASDEV has never really been a single computer.

Although it started life as a network attached storage system, over time it evolved into a small infrastructure platform supporting storage, applications, development environments, networking and experimentation.

One of the interesting aspects of NASDEV is that the architecture has evolved organically rather than being designed in its current form from day one.

That evolution has resulted in a system that is perhaps a little unconventional — but also extremely useful as an engineering platform.

The Foundation

At the heart of NASDEV is a Solaris-based system.

Solaris provides the underlying operating environment, while ZFS provides the storage foundation.

This combination has been particularly valuable because it provides much more than simply somewhere to put files.

ZFS gives NASDEV pooled storage, filesystem-level management, snapshots and data integrity features, while Solaris provides the operating-system environment in which the various services and applications can run.

This has become the foundation on which everything else is built.

Zones: Separating the Services

One of the things I particularly like about Solaris is the concept of Zones.

Rather than running every service directly in the global zone, NASDEV uses separate zones to isolate different functions.

This provides a useful compromise between running everything on separate physical machines and putting everything into a single operating-system environment.

A zone can have its own filesystem hierarchy, network configuration, services and applications while still sharing the underlying hardware and Solaris kernel.

That makes it possible to treat individual services almost like separate machines without the overhead of maintaining a collection of physical servers.

Over the years NASDEV has accumulated zones for different purposes, including storage, databases, web services, development and experimentation.

The exact configuration has changed over time, but the principle has remained the same:

Separate things that have different purposes.

Storage

Storage is still one of NASDEV's primary functions.

The underlying ZFS pool provides the shared storage used by the various services and systems.

This separation between the storage layer and the applications is important.

Applications don't need to know how the physical disks are arranged.

They simply use the filesystems and datasets made available to them.

That means the storage architecture can evolve without necessarily requiring every application to be redesigned.

It also provides another important advantage: snapshots and filesystem-level management can be performed independently of the applications using the data.

Network Services

NASDEV also provides a number of network services.

Some services are deliberately isolated into their own zones, while others run closer to the underlying system.

A reverse proxy provides another layer between external access and the internal services.

This is particularly useful because it allows services to remain internally separated while still presenting a coherent external interface.

From the outside, the system can look like a single service.

Internally, it is anything but.

Web Services

The NASDEV website itself is now another component of the system.

Joomla provides the content management layer, with PHP and the web server running within the appropriate environment.

This has created an interesting situation where NASDEV is now documenting itself.

The system hosts the website that documents the system.

There is something rather satisfying about that.

The documentation isn't being written about an abstract laboratory environment. It is being written on the infrastructure that is actually being discussed.

Development and Experimentation

Another important characteristic of NASDEV is that it isn't treated as a completely static production appliance.

It is also an engineering laboratory.

New software gets tested.

Configurations get changed.

Operating systems get upgraded.

Services are added and removed.

Sometimes things break.

That's intentional.

A system that can never be changed because nobody knows what might happen is difficult to learn from.

The challenge is finding a sensible boundary between experimentation and the services that need to remain reliable.

Zones, datasets, snapshots and good separation between services make that considerably easier.

Why Not Just Use Virtual Machines?

Virtual machines are an obvious alternative.

They provide excellent isolation and are extremely useful in many environments.

But NASDEV doesn't necessarily need a complete virtual machine for every service.

Solaris Zones provide much of the isolation required while introducing considerably less overhead.

They also fit naturally into the Solaris architecture.

For NASDEV, this has proven to be a very practical approach.

It isn't necessarily the right architecture for every environment.

But it is the architecture that makes sense for this one.

The Architecture Is Always Changing

One of the things worth remembering about NASDEV is that the architecture shown today isn't necessarily the architecture that will exist tomorrow.

Technology changes.

Requirements change.

Hardware fails.

Better solutions become available.

Some services become obsolete.

Others become important enough to justify their own infrastructure.

That's part of the project.

Rather than trying to design the "perfect" architecture and then freeze it, NASDEV has been allowed to evolve.

Some of the resulting decisions have been excellent.

Others probably wouldn't survive a modern architecture review.

But every one of them tells a story.

The Philosophy

Ultimately, the NASDEV architecture follows a fairly simple philosophy:

Keep the foundation stable.

Separate services where practical.

Keep storage independent from applications.

Experiment without putting everything else at risk.

Document what happens.

And perhaps most importantly:

Understand the technology rather than simply operating it.

That last point is probably the best description of NASDEV as a whole.

It isn't intended to be the most modern infrastructure platform.

It isn't intended to compete with commercial NAS appliances or enterprise datacentres.

It exists because building and understanding systems is interesting.

And after many years, NASDEV has become a rather good environment in which to do exactly that.