Note that the three-tier architecture consists of the following:
- Presentation tier – consists of the components that users interact with; this might include web pages and/or mobile app user interface components
- Logic-tier – contains the code required to translate user actions initiated at the presentation tier to the functionality required by the application
- Data-tier – consists of storage media that hold the data relevant to the application architecture; this might be a database, object stores, caches, or file systems
AWS offers many technologies to assist with the presentation tier of your architecture. The Amazon Cognito service can assist with the creation and management of user identities. S3 might be the source of any static Web content you need to store and the deliver for the tier. The API Gateway can be enabled for cross-origin resource sharing compliant. This permits web browsers to invoke APIs from within your static web pages.
You can consider the logic tier to be the “brains” of the architecture. This certainly lends itself to the power of the API Gateway and Lambda functionality. They combine to allow a revolutionary new serverless approach to the multi-tier architecture. Thanks to advantages that come with serverless implementations, new levels of high availability, scalability, and security are possible. While a more traditional server-based implementation of the three-tier architecture might require thousands of servers in order to scale, a serverless environment does not need a single virtual server in its operation.
The data tier of your architecture can be utilized with a wide variety of AWS solutions. We often organize these into two broad categories. Amazon VPC-hosted data stores and IAM-enabled data stores. VPC-hosted data store options include:
- RDS – several relational database engine options here
- ElastiCache – boost performance with in-memory caching
- Redshift – simple data warehousing capabilities
- EC2 – data stored within technology offered by an EC2 instance(s)
IAM-enabled options include:
- DynamoDB – an infinitely scalable NoSQL database
- S3 – infinitely scalable object-based storage
- Elastisearch Service – a managed version of the popular search and analytics engine called Elastisearch
As we discussed in the previous post in this category, we know that Cisco NX-OS Software provides isolation between the control and data plane within a Nexus device. This isolation means that a failure within one plane does not disrupt the other plane. Great!
In this post, let’s elaborate more on the fact that a process cannot only be restarted if it fails but restarted statefully. Meaning the process has information that existed prior to the failure.
When a restartable service fails, it is restarted on the same supervisor. If the new instance of the service determines that the operating system abnormally terminated the previous instance, the service then determines whether a persistent context exists.
The initialization of the new instance attempts to read the persistent context to build a run-time context that makes the new instance appear like the previous one. After the initialization is complete, the service resumes the tasks that it was performing when it stopped. During the restart and initialization of the new instance, other services are unaware of the service failure. Any messages that are sent to the failed service by other services are available from the Message and Transaction Services (MTS) when the service resumes.
The success of the new instance in surviving the stateful initialization depends on the cause of failure of the previous instance. If the service is unable to survive a few subsequent restart attempts, the restart is considered as failed.
In cases where the stateful restart fails, the System Manager performs the action that is specified by the high-availability (HA) policy of the services. This action forces one of the following:
- Stateless restart
- No restart
- A supervisor switchover
- A reset
During a successful stateful restart, there is no delay while the system reaches a consistent state. Stateful restarts reduce the system recovery time after a failure.
Let’s examine a step by step example of stateful restart in action!
- During normal operation, the running services make a checkpoint of their run-time state information to the Persistent Storage Service (PSS)
- During normal operation, the system manager monitors the health of the running services using heartbeats
- The service encounters a fatal error
- The system manager restarts the service instantly when it crashes or stops responding
- After restarting, the service recovers its state information from the PSS and resumes all pending transactions
- If the service does not resume a stable operation after multiple restarts, the system manager initiates a reset or switchover of the supervisor
- Cisco NX-OS collects the process stack and core for debugging purposes with an option to transfer core files to a remote location
I hope this has been informative for you, and I would like to thank you for reading!