….that would be next Tuesday for those like myself who don’t have a built-in calendar function in their cranial cerebrum…..
Now that tax day is over (for those of us here in the USA…..my friends in Canada still got a few weeks of fretting to do), we can get on with life – and that means keeping up with where technology is going as well as doing our jobs. I put it that way as often we don’t have time while doing our jobs to keep up with things, do we???
Anyhow, next week, I am presenting in a webcast about ASE Cluster Edition (ASE CE) – both from what is available today as well as where we think we are going. If you got the email about it, you probably saw that topics for discussion include:
- A brief/quick history of ASE clustering (for those who are not familiar with all of our past successes….and not so successes)
- A brief walkthrough of ASE CE workload management and how this applies to availability
- A discussion on SP130 features including Single Instance Database (SIDB) and cluster locking enhancements
- A fairly thorough discussion on ASE CE and rolling upgrades (imminently available)
- ASE CE 16 roadmap
If you missed the email or it went SPAM folder automatically, you can register here:
With respect to the discussion topics, the last bullet point is one that I think we need to be a bit more upfront about. We have often discussed roadmaps in a general sense and maybe in some cases referred to some specifics with respect to planned functionality. However, as an ex-DBA myself, I know that it is often desirable to understand some of the challenges and decisions that may drive product development one way or another….vs. waiting until the product is GA and then trying to find out *why* some engineer made a particular decision that seems sooooo… counter-intuitive. I have made it part of my goals in product management to help customers understand why certain implementations were chosen – as much as a way of educating about the technology but also simply to head-off a lot of the “why didn’t you ….” objections/questions raised a lot around key topics. As a result, we will have a short discussion during the webcast about metro/stretch clusters (or whatever your preferred term is) so that we all understand some of the challenges we are facing in some of the future roadmap items. This should be a key clue that if such features are important – now is the time to help us understand your requirements so as to help us set priorities.
We also will have a short discussion on horizontal scalability – although there are some internal folks at SAP that might be a bit concerned about that. To me, not discussing it is like ignoring the enraged bull elephant in the same room as you are….and it’s between you and the only door you can escape out of. Oft times, I have found that those really desiring horizontal scalability don’t really realize that shared disk clusters have inherent limitations in this area. In fact, those pursuing horizontal scalability usually break out into one of several different classifications:
- Those looking to exploit the cluster hardware vs. a sunk cost (TCO play) by spreading workload across the machines
- Those looking to recapture some of the performance overhead of SDC on their applications be leveraging the other node to make up for any loss of performance
- Those that actually could leverage such a solution (rare – but exists) – but may not understand how SDC implementations may frustrate their best efforts
- Those who have read about it and in their irrational exuberance embark on a science project… incontrovertibly destined for failure
….so, we will take a brief look at why applications think they need horizontal scalability as well as what technologies are actually necessary to achieve the scalability or to work-around issues. Don’t get me wrong – clustering overall is a common technique for scalability – Hadoop/Map Reduce and many other implementations thrive on it. But shared disk clusters, such as ASE CE, Oracle RAC and IBM DB2 PureScale – all share a lot of similarities with scalability limitations based on what we used to call computer science 101 issues…..or perhaps it should be 301 as it definitely is a bit more of a complex topic that programming “hello world”.
See you on Tuesday!