tag:blogger.com,1999:blog-4285729513030543746.post8592877888218973753..comments2024-03-27T00:26:40.551-07:00Comments on Real Time View: NonStop revels in Clouds!Richard Bucklehttp://www.blogger.com/profile/17723428627971060930noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-4285729513030543746.post-66766131968773083232011-08-24T13:46:34.518-07:002011-08-24T13:46:34.518-07:00Yes you are correct the Limux serverclasses receiv...Yes you are correct the Limux serverclasses receive and reply through standard stdin & stdout. The API does not include calls to handle $RECEIVE - that is handled by the Gateway Server portion of GuardianAngel.Justinnoreply@blogger.comtag:blogger.com,1999:blog-4285729513030543746.post-11528124692736082562011-08-24T08:00:48.014-07:002011-08-24T08:00:48.014-07:00We have a very lightweight portable application pr...We have a very lightweight portable application programming interface (API) that allows inter-system messaging for the purposes of this capability. For example, when we demonstrated the Java Pet Store application, we were able to move Java code (binary jar files) as-is from system to system to allow java frameworks to abstract the access calls. In other words, using Java, we have to only write a portable data access object (DAO) that used these "GA API" calls. That was the only change necessary to make Java Pet Store software exploit this capability. <br />I hope this helps.Keith Moorehttps://www.blogger.com/profile/11463232898146308826noreply@blogger.comtag:blogger.com,1999:blog-4285729513030543746.post-13508318009639528622011-08-24T07:17:43.778-07:002011-08-24T07:17:43.778-07:00Copied from the LinkedIn group, Pyalla Technologie...Copied from the LinkedIn group, Pyalla Technologies:<br /><br />You said, "When we say instances running on Linux, Public Cloud and NonStop it probably would have been better to say instances of serverclasses running on these various platforms".<br /><br />Just to clarify, is it correct to assume that the Linux version of the serverclass simply uses stdin / stdout to receive transactions and reply to them? Are there any Guardian Angel-specific api calls that must be made, analogous to $RECEIVE READUPDATE / REPLY?<br /><br />Neil Coleman,<br />Infrasoft Pty LtdAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-4285729513030543746.post-54709361679396510862011-08-17T10:57:07.798-07:002011-08-17T10:57:07.798-07:00(Continued from above)
There is also a side benefi...(Continued from above)<br />There is also a side benefit to some of the hardware that make NSGA even more viable now than this same architecture would have been on past NonStop servers. Portions of the TCP/IP stack are now "offloaded" to IP-CLIM "controllers". Becuase of this, the TCP/IP processing no longer competes against application logic for Itanium cpu cycles. This NSGA design benefits from this, as do many newer NonStop applications. <br /><br />The team is well aware of the need for database synchronicity within the designs of these types of systems. This is no different than it is today with various cross-platform application implementations. Oracle replication is commonly used for non-NonStop database, GoldenGate, Attunity, Gravic Shadowbase are commonly used to manage cross-platform database synchronicity. However I think that because of the newer, more commonly used application frameworks (Axis, MyServerFaces, iBatis, Hibernate) running under MVC pattern, this data synchronization is managed more-or-less as an application access issue instead of the traditional problem of cross-platform replication. In other words, current data access frameworks are database agnostic and allow us (generic “us” application designers) to deploy to various databases and ‘assume’ that the data server will provide ACID access with lock protection. And the frameworks allow for lock requests to persist via the DAO. Fortunately, Pathway allows us to initiate and retry/recover transactions way up at the start point if NonStop is at the base of the transaction (and not subordinate to another transaction). We demonstrated a multi-database using Java POJO frameworks and Pet Store. The use of a data access object (DAO) is exactly what I describe here. The DAO abstracts the database implementation from the usage. This allows the application architect to designate how it needs to protect from failure/retry/collision. <br /><br />I am a CISSP and look at these implications regularly. I completely agree that there are significant issues associated with public cloud (and private cloud, for that matter) when it relates to movement of data, and ownership/responsibility of sensitive information of all types. It is not part of our demonstration to address this issue directly. However, we have all been aware of it as we demonstrate this capability. <br /><br />We did not hide the delay in startup of the actual virtual server. We just decided for the demonstration, not to show it. In effect, this is a CREATEDELAY activity and would be deployed just like this old-fashioned “NEWPROCESSCREATE” calls that we made on our old TXPs. I do recall recommending that we minimize how often we do this because often a transaction would queue waiting for a NEWPROCESS to occur. This is an extreme version of this same create problem. Creating a new virtual machine does take some time. But it does work (with about an 8 minute delay in a public cloud). Also note that the pathway still does the DELETEDELAY (dissolve) the servers when not needed. The most painful part of our show demonstration is when we have to wait for the “DELETEDELAY” to happen at the end of the demonstrations. This is representative of why we chose to just use existing servers that we created in the cloud. Also note that the typical public cloud pricing model allows us to leave these running for a long time with only pennies of expense. In the real world, I would assume a mix of these services; some pre-booted, and some not. <br /><br />The design of applications that use this NSGA approach will assume that the application architect has researched and designed a service-based business implementation with varying service level agreements (SLAs) for the components. Armed with this design, the NSGA methods of use for TS/MP can significantly improve efficiency of most of the various server types where the business services will run. <br /><br />I hope that this helps. <br />- Keith M.<br />(End)Keith Moorehttps://www.blogger.com/profile/11463232898146308826noreply@blogger.comtag:blogger.com,1999:blog-4285729513030543746.post-50205692012104742002011-08-17T10:55:26.521-07:002011-08-17T10:55:26.521-07:00Keith Dick brings up some very good points. My re...Keith Dick brings up some very good points. My reply is too big to fit in one posted reply. Please excuse my verbosity, but I am hoping that this information helps...<br />- Keith Moore<br />Hello Keith. I haven't seen your name in a long time. It's good to hear from you. <br /><br />I will try and address these questions (in addition to Justin's comments). Hopefully, I won't confuse or contradict anything already said.<br /><br />Pathways Serverclasses are instantiated on Linux (or Windows) under PATHMON control as-if they were local to NonStop. This allows TS/MP to manage creation/deletion, and recovery of business-level application services running on or off the NonStop platform. The value is in that NonStop is always-on and can reliably manage these services based upon performance queue metrics. I don’t need to explain Pathway to you, for sure! So it’s not PATHWAY instances, it is PATHWAY SERVERCLASS instances. <br /><br />“Low-value” transactions. We have struggled with terminology here. Being NonStop biased, we consider all transactions to be “high-value”. However, as Napoleon the pig said in Animal Farm, some transactions are “more equal” than others. And in fact, some portions of some transactions, are more equal than others. The idea is that in the real world of application services, some portions of a transaction are not necessarily in need of all of the NonStop fundamentals. Most often, this is because of lack of need for tight cross-transaction synchronicity, lock management, external databases, data-free, process-heavy activity. Examples would be browse-before-buy, fraud-analysis engines, market analytics, commodity pricing lookup, and etcetera. Also, there are some COTS applications that need to integrated into transaction services that need NonStop fundamentals. Examples of this are, again, Analytics engines, SAP applications, and Oracle apps and database. We don’t mean that they are “low-value” as much as perhaps they are context-free, retry-able, or in some way not in full need of the full reliability of NonStop. Most commonly, this is COTS or context-free application access as part of a greater transaction that needs to be running on NonStop. Another common example is where, as part of a NonStop “money transaction” the application exit needs to go to a “less reliable” source to get a risk assessment or fiscal “position”. In the past, if the transaction could not get to the remote service, then stand-in logic would be required. This is still the case, but instead, the application can be designed to use TS/MP to maintain multiple instance of this service on other physical of virtual servers. With private cloud, this is likely common today except that the service management is at the SERVER level, not the application-level. This is one of the key values of NSGA. <br /><br />A specific example of this is in the travel industry where a single request from a travel website (orbits, expedia, etc) can generate many transactions at the travel booking site. At a car rental agency, a single car rental discovery could include up to 20 rate/car class lookups, location hours of operations and vehicle availability. Using the NSGA architecture, an application will receive that single request and farm-out rate and availability requests to different pools of commodity servers; then formulate a single reply back. This would be all under cover of one transaction with several "lighter-weight" (or retry-able, context-free) query transactions within it. This is a common travel industry function. <br />(Continued)Keith Moorehttps://www.blogger.com/profile/11463232898146308826noreply@blogger.comtag:blogger.com,1999:blog-4285729513030543746.post-48966708065531090962011-08-13T22:12:42.659-07:002011-08-13T22:12:42.659-07:00Keith, As they say 'good questions'. As a...Keith, As they say 'good questions'. As a member of the GuardianAngel team let me try and address them. When we say instances running on Linux, Public Cloud and NonStop it probably would have been better to say instances of serverclasses running on these various platforms. Pathway itself must run on NonStop (at least today) since it is a process-pair subsystem. Pathway or should I say Pathmon, is overseeing the serverclass instances running on the various platforms through the gateway serverclass that uses the GA-API.<br />Common database was the number one question in Las Vegas at Discover. For the demo we use NonStop SQL/MX on NonStop but used an in-memory database for Linux and the cloud. These were kept in sync by doing a dual write. Since SQL/MX was the only database that had update activity (buying a pet - in memory DB merely displayed info about pets) - all updates were from NonStop to the in-memory database. Since there are so many flavores and versions of database that is something we would address individually at customer workshops (but we have thought a lot about it).<br />I'm not sure hiding the start-up time was misleading but we can concede the point. Amazon server start-up takes 2-8 minutes. We felt 2-8 minutes of watching a bar graph eventually go to 100% would have lost us most of our audience in Las Vegas but point taken. There is no way to speed Amazon or any other public cloud up unless you have instances pre-started. Everyone suffers the 2-8 minute start-up delay. In a real situation you would have to start based on an exceeded threshold and hope everything was ready by the time you ran out of resources which is a public cloud limitation not a GuardianAngel one.<br />In terms of 'low-value' it is probably application dependent. You are absolutely correct running these, even as a message switch, through NonStop adds to the overall path-length. Is it worth it? Well I am of the belief that 'low-value' does not necessarily mean 'no-value'. By running it through NonStop you are guarding against a complete outage - I know that's something almost unheard of in public clouds...but still it could happen..8^) So by running it through NonStop we would have the capability of preventing a full outage and in our example, and I believe in most instances, the high-value transactions are actually dependent on the low-value. That-is would you buy a pet from pet store without first seeing it?<br />Final point about the NonStop application and sensitive data in the public cloud is spot on. That would really need to be evaluated before bursting any part of a NonStop application into a public cloud. However as we said in the demo - bursting could actually occur to another NonStop system not a cloud. What if, under this rare occurance where processing was exceeded that you 'burst' to your NonStop development system? Or perhaps there was an HP NonStop private cloud you could burst to? Please don't imply any future HP commitments from that statement - it is a personal question only.<br />Hopefully I've addessed the questions if not please post again.Justinnoreply@blogger.comtag:blogger.com,1999:blog-4285729513030543746.post-23160149006615184902011-08-11T22:07:17.652-07:002011-08-11T22:07:17.652-07:00This is the first description of that GuardianAnge...This is the first description of that GuardianAngel demo that I have seen. Thanks for writing it.<br /><br />It does raise a few questions.<br /><br />One of the things you said is: "... so Pathway instances using the same code base are running on Linux, in a public cloud and on NonStop all at the same time under the control of Pathway ...". Did you really mean to say that Pathway instances run on Linux and in a public cloud, or did you mean that Pathway server instances were running there?<br /><br />How is it arranged that the servers running in all three places access a common database? Arranging to have servers running on Linux and a cloud service like that is a nice trick, but if they aren't sharing a common database, I'm not sure it is very useful.<br /><br />Hiding the time it would take to start up the overflow servers on the public cloud service seems to be a bit misleading, unless the folks doing the demo believe they know how to reduce that start up time to a few seconds, but were not able to do the work needed in time for the demo. Or am I overlooking something about that?<br /><br />Another quote: "... and low-value transactions being dispatched into the cloud, all managed by Pathway." I wonder whether it makes sense to have the low-value transactions flow through the NonStop system. If the system architects consider the transactions to be low-valued, they probably would not want to spend any NonStop resources on them. I imagine a lot of the cost of processing occurs before that switching point, so if they enter through the NonStop system, I imagine that recognizing and forwarding them to the cloud would cost almost as much as it would to do all the processing in the NonStop system, and so would be unattractive. And even if the low-value transactions don't enter through the NonStop system, but access the database on the NonStop system, that is putting a fair chunk of the processing on the NonStop system. Am I guessing wrong on those points, or does it actually not make very much sense to have low-value transactions touch the NonStop system at all?<br /><br />Using a public cloud as an "emergency CPU upgrade" does seem like a valuable capability, as long as the implications of sending possibly-sensitive data out of the company's data center are taken into account, but I wonder a bit about the notion of designing a system to work that way under normal loads. For instance, the NonStop system might pretty quickly become a bottleneck. Or the resources needed to send transactions to the cloud might be comparable to the resources needed to process the transactions locally, especially if the database they use is on the NonStop system. Do you know how closely those sorts of things have been studied? And if it does turn out that there is not such a big win to offloading transactions to the cloud, I guess that kind of undermines the notion of using this mechanism as an emergency CPU upgrade, too.Keith Dicknoreply@blogger.com