Tag: SMF

SmartDataCenter, the Open Cloud Platform that Actually Already Works


For years enterprises have tried to make OpenStack work and failed miserably. Considering how many heads have broken against OpenStack, maybe they should have called it OpenBrick.

Before I dive into the details, I’ll cut to the chase. You don’t have to break your heads on cloud anymore. Joyent have open sourced (as in get it on Github) their cloud management platform.

It’s free if you want (install it on your laptop, install it on a server). It’s supported if you want. Best of all, it actually works outside of a lab or CI test suite. It’s what Joyent runs in production for all their public cloud customers (I admit to being one of the satisfied ones). It’s also something they have been licensing out to other cloud providers for years.

Now for the deep dive.

What’s wrong with OpenStack?

First off, it isn’t a cloud in a box, which is what most people think it is. In 2013,Gartner called out OpenStack for consciously misrepresenting what OpenStack actually provides:

no one in three years stood up to clarify what OpenStack can and cannot do for an enterprise.

In case you’re wondering, the analyst also quoted Ebay’s chief engineer on the true nature of OpenStack:

… an instance of an OpenStack installation does not make a cloud. As an operator you will be dealing with many additional activities not all of which users see. These include infra onboarding, bootstrapping, remediation, config management, patching, packaging, upgrades, high availability, monitoring, metrics, user support, capacity forecasting and management, billing or chargeback, reclamation, security, firewalls, DNS, integration with other internal infrastructure and tools, and on and on and on. These activities are bound to consume a significant amount of time and effort. OpenStack gives some very key ingredients to build a cloud, but it is not cloud in a box.

The analyst made it clear that:

vendors get this difference, trust me.

Other insiders put the situation into similar terms:

OpenStack has some success stories, but dead projects tell no tales. I have seen no less than 100 Million USD spent on bad OpenStack implementations that will return little or have net negative value.Some of that has to be put on the ignorance and arrogance of some of the organizations spending that money, but OpenStack’s core competency, above all else, has been marketing and if not culpable, OpenStack has at least been complicit.

The motive behind the deception is clear. OpenStack is like giving someone a free Ferrari, pink slip and all but keeping the keys. You get pieces of a cloud but no way to run it. Once you have put all your effort into installing OpenStack and you realize what’s missing, you are welcome to turn to any one of the vendors backing OpenStack for one of their packaged cloud platforms.

OpenStack is a foot in the door. It’s a classic bait and switch but even after years, no one is admitting it. Instead, blue chip companies fight to steer OpenStack into the direction that suits them and their corporate offerings.

What’s great about SmartDataCenter?

It works.

The keys are in the ignition. You should probably stop reading this article and install it already. You are likely to get a promotion for listening to me 😉

Great Technology

SmartDataCenter was built on really great technologies like SmartOS (fork of Solaris), Zones, ZFS, and DTrace. Most of these technologies are slowly being ported to Linux but they are already 10 years mature in SDC.

  • Being based on a fork of Solaris brings you baked in enterprise ready features like IPSEC, IPF, RBAC, SMF, Resource management and capping, System auditing, Filesystem monitoring, etc.
  • Zones are the big daddy of container technology guaranteeing you the best on-metal performance for your cloud instances. If you are running a native SmartOS guest, you get the added benefit of CPU bursting and live machine re-size (no reboot, or machine pause necessary).
  • ZFS is the most reliable, high performance, file system in the world and is constantly improving.
  • DTrace is the secret to low level visibility with zero to no overhead. In cloud deployments where visibility is usually close to zero, this is an amazing feature. It’s even more amazing as the cloud operator.


SDC was built for one thing by one company, to replace the data centers of the past. It says so in the name. With one purpose, SDC has been built to be veryopinionated about what it does and how it does it. This gives SDC a tremendous amount of focus, something sorely lacking from would-be competition like OpenStack.

Lastly, it works.

Sun Webstack 1.4 – Packages on Crack

I am a huge fan of Sun Microsystems.
I love Solaris 10.
I love ZFS.
I love RBAC.
I love zones.
I really love T2/T2+ processors.
I especially love the T5140 and X4450 servers.

One thing I cannot figure out though, is why Sun lets obviously delirious cocaine addicts package their software. Maybe I’m exaggerating but I think that many will agree that Sun’s packages leave much to be desired in general. On top of that, Sun seems to have a constant need to move software around and invent new paths- to boldy go where no sysadmin has gone before????

Our journey begins with the mythic /usr/ucb/ directory- a true treasure chest for those making the adjustment from Linux. We’ll continue to /usr/local/ ala sun freeware (actually the most normal place we will visit but not actually supported by sun) and then arrive at the more recent /usr/sfw.

On your right, we’ll be passing the Coolstack project (Not Officially Supported by Sun) located reasonably in /opt/coolstack. Notice the configuration files in /opt/coolstack/etc, apache located comfortably in /opt/coolstack/apache2, mysql located in /opt/coolstack/mysql. Can anyone guess where the SMF manifests are? My first guess would have been /opt/coolstack/var/svc… similar to the native manifests but I would be wrong because that would make too much sense or be too easy. Anyway- they are hiding in /opt/coolstack/lib/svc…

Wait- what’s that ahead? Coolstack is falling into disrepair, no longer to be updated. Instead, there will be a new neighborhood called Webstack and it WILL be officially supported by Sun- Time to get high. Can’t figure out where anything is? I’ll give you some hints:

Looking for configuration files? Don’t try /etc or /opt/webstack/etc. You should be looking in /etc/opt/webstack ??!?! Since when does that directory even exist?

Looking for your MySQL data directory? Don’t try /opt/webstack/mysql/data (similar to the existing structure in coolstack). Bet you wouldn’t have guessed /var/opt/webstack/mysql/5.0/data – /var/opt ??!?! What is that? Maybe for the 1.5 release they could put it in /usr/ucb/opt/usr/local/var/spool/sfw/webstack/mysql/5.0/data?

How about your default DocumentRoot for Apache? You must have guessed it by now: /var/opt/webstack/apache2/2.2/htdocs

Anyone here running webstack on Linux? In that case all the directories are different. I guess Sun wanted to make it difficult to run their stack on heterogenous environments?

Seriously- I really hope Sun wises up and fixes this before they hope for widespread adoption of the 1.5 release.

Persistent static routes in Solaris 10 11/06, 08/07

Static routes are a very common necessity once your networks become even a little complex. Whether you need to route specific traffic over a VPN or setup specific test addresses for IPMP failover, static routes are indispensable.

For many years the “correct” way of configuring static routes in Solaris has been to create an init.d script which ran the ‘route add’ commands.

As of Solaris 10 11/06, a more reasonable approach has been implemented. The ‘route’ command has a new option ‘-p’.

Make changes to the network route tables persistent across system restarts. The operation is applied to the network routing tables first and, if successful, is then applied to the list of saved routes used at system startup. In determining whether an operation was successful, a failure to add a route that already exists or to delete a route that is not in the routing table is ignored. Particular care should be taken when using host or network names in persistent routes, as network-based name resolution services are not available at the time routes are added at startup.

Now you may be asking “Where is my configuration file?” The route command currently stores your static routes in the file /etc/inet/static_routes but this has been declared volatile. Sun is not promising to keep these configurations in that file or in the same format from release to release.

I personally am not happy with Sun’s general move to administrative utilities for configuration as opposed to configuration files. I agree that utilities are useful. They ensure correct syntax, etc. but I want the ability to configure a system on the file system level as well. Otherwise I loose the ability to keep a system’s configuration files in version control. I loose the ability to deploy a system by transferring the appropriate files (ala scp, cfengine, puppet, home grown script, etc.) I prefer something along the lines of crontab where the syntax is checked but the configuration itself is a file in userspace.

Still, a standard method for configuring static routes is welcome in place of creating init scripts, especially with SMF services phasing out init scripts altogether.