by Sowmiya Subramanian | Jul 11, 2019 | BizTalk Community Blogs via Syndication
Monitor Host Instances in Clustered/High availability environment
A BizTalk Server Host is a logical container that contains the BizTalk Server runtime processes in which you deploy items such as adapter handlers, receive locations (including pipelines), and orchestrations. The host instance is the runtime process where the message processing, receiving, and transmitting occurs. Obviously, it is very important to ensure your host instances are running in your BizTalk environment. BizTalk360 already made it easy for its customers by introducing the Host Instance Monitoring functionality. In BizTalk360, you can monitor the BizTalk host instances by setting the Expected State. If the expected state doesn’t match with the current state of the host instance, you will get notified.
Out of the box, BizTalk360 allows users to monitor the Clustered Host Instances using the “AtLeastOneActive” state.
If this state is assigned as the Expected State, then the monitoring service will verify that across all the instances for the respective clustered host, at least one host instance is active, guaranteeing that the server is running, and no downtime happened for that host/server. To know more about Clustered Host Instance monitoring, follow this blog link.
In the upcoming BizTalk360 version 9.0 Phase 2, we have extended this core functionality to monitor the host instances for high availability environment, as per the customer feedback and voting as below.
BizTalk Server High availability
The following figure shows a BizTalk Server deployment that provides high availability for the receiving host by having two host instances on different computers. Note, that in this figure the processing and sending host is not highly available, because there is only one host instance processing the BizTalk items assigned to the host.
How BizTalk360 helps to monitor the Host Instances in clustered/High availability Environments?
In a business scenario, if you have two BizTalk servers and they both have a Host Instance on them called “FTP”, both Host Instances will trigger a connection to this FTP server. If a file exists on the FTP server that matches your Receive Location’s file mask, both of these host instances will attempt to retrieve a copy of this file, as shown below.
To avoid processing duplicate messages from the high availability, organizations may use the Windows Clustering. This will guarantee that only one host instance is running at a time.
In the above cases, any one of the BizTalk servers needs to be in the active state to receive the file, if both the server is down, then the file will not get received. With BizTalk360, a user can monitor both the host instances in different servers, by setting up the “AtleastOneActive” State as shown below.
In High Availability environments, users can have all the host instances to be Active. For example, if you have 3 BizTalk Host Instances, in multiple BizTalk servers, used for different purposes like receiving, processing and sending the files.
You can set up monitoring for the above scenario in BizTalk360, by setting the expected state to Started for all the three Host Instances as you can see below. When any of the host instances goes down, you will be notified.
Setting up the “AtleastOneActive” state for Host Instances
The “AtleastOneActive” state is mainly used to monitor the Active/Passive clustered and Non-clustered host instance monitoring. The user can set the “AtleastOneActive” state only for clustered host instances and non-clustered host instances in high availability environment.
Setting the “AtleastOneActive” state will monitor across all the configured host instances of the same host and check if any one of the host instances is active. If so, the monitoring state will be healthy.
If all the configured host instances are down or stopped state, then the host instance monitoring will turn to Critical state.
The monitoring status of the host instances will get reflected in the BizTalk360 Monitoring dashboard and the same will be notified in detail in the alert email.
How does AutoCorrect functionality work for the AtleastOneActive state of the host Instance monitoring?
Do you feel frustrated to manually start host instances, when all the host instances become down in clustered/High availability environment?.
BizTalk360 comes up with another solution with its Auto Healing capability.
For Example, if you have 2 BizTalk host instances running under Clustered/high availability setup, from 2 host instances any one instance needs to be in the active state for performing file transactions. If both the host instances are down, then you need to start the host instances manually. This requires continuous monitoring, which can be handled by BizTalk360 itself, by configuring the AutoCorrect functionality to the clustered or non-clustered host instances.
In the above screenshot, the auto-correct functionality is enabled for 2 host instances in different BizTalk servers BTS1 and BTS2. If both the host instances are down, from next monitoring cycle BizTalk360 will try to auto-heal any one of the host instances from these servers. On the first attempt, it will try to start the host instance in BTS1 server. If the instance is started successfully then it skips auto-healing the next server BTS2. In case BizTalk360 fails to start the instance in BTS1, then it tries to start the host instance on the server BTS2. BizTalk360 will try to start any one of the host instances until it reaches the maximum attempt count. You can also reset the auto-correct by setting the reset interval. To know more about the auto-correct feature click here.
Conclusion
Monitoring the Host Instances in Clustered and High availability environment is a must for a healthy BizTalk environment. BizTalk360 monitors those host instances in an easy and simple manner. It also manages the host instances and ensures they are up and running, by using the auto-correct functionality. The upcoming version of BizTalk360 will ease your way of monitoring the host instances in clustered and high availability setup.
The post Monitor the Host Instances in Clustered/High availability environment appeared first on BizTalk360.
by Praveena Jayanarayanan | Jul 4, 2017 | BizTalk Community Blogs via Syndication
BizTalk360 is a single platform to have total control over your BizTalk environment. It has the three main modules namely Operations, Monitoring and Analytics. Monitoring is considered as the main feature of BizTalk360 because it provides rock solid monitoring for the BizTalk environment and informs us via email alerts when the BizTalk server is suffering from problems and downtimes.
As per the below quotes,
“Listening to our customer’s feedback makes them feel appreciated and part of the value creation process”,
We always listen to their valuable suggestions and feedback and add them to BizTalk360 in every upcoming release. We also make enhancements to the existing features based on the customer feedback. This blog explains about one such enhancement on actions performed on the suspended instances.
MessageBox Queries Monitoring:
Data Monitoring was one such feature included in BizTalk360, from the customers’ feedback. Data monitoring helps to monitor the send/receive ports, service instances and exception data from different data sources in BizTalk server. Message Box Queries monitoring is a part of Data Monitoring which is used to monitor the service instances. The service instances may be running or may get suspended in BizTalk servers due to various reasons.
The messaging service instance is the service instance that’s created for your receive and send port at the run time. A receive port/send port is a combination of various things. Ex: An adapter (File, WCF, SQL etc.), a receive pipeline (and a send pipeline if two-way), and Maps. They get instantiated like the objects for the classes and have different states in their lifetime namely,
- Ready to Run
- Scheduled
- Dehydrated
- Suspended (Resumable)
- Suspended (Non-Resumable)
- Active
- In Breakpoint
Here in monitoring, we can monitor the count of these instances at various stages and the alerts will be triggered based on the filters and threshold value configured. It is important to monitor the number of service instances, to keep the BizTalk environment healthy. Having many instances will make the MessageBox database bloated which in turn will affect the performance of the environment. The service instance count can be retrieved from BizTalk Administrator group hub page which displays only the count and does not tell you if it’s the expected count or not. A person seeing this information needs to be a BizTalk expert to understand the various states. Here comes our MBQ monitoring which alerts users according to the threshold limit configured. A non-BizTalk person can now easily understand the alert message and act accordingly.
Actioning on the suspended service instances:
Based on the state of the service instances, the administrator can decide on whether to resume or terminate the instances. For example, when a message is sent through the send port and if it’s stopped, then the instance gets suspended. Once the send port is up, the message can be resumed and processed. Instead of going to the BizTalk admin console and checking it, BizTalk360 has the feature to terminate/resume the instances from the monitoring itself. We can also configure the time when we want to perform the action, either every time or during Error/Warning condition.
So, what happens when Action Required is ticked?
There may be scenarios wherein, the customer wants to monitor any suspended messages that by the end of the day are no longer relevant and should be terminated. So, in this case, BizTalk360 can automatically terminate the instances as per the alarm configuration. This can avoid the excess workload to the BizTalk user as he needs to go and manually run the query to find the instances and action it. We also have the option to bulk terminate the suspended instances altogether instead of doing one by one. There is also an archiving option and to download the instances.
Can non-super users terminate/resume suspended instances?
We have two kinds of users in BizTalk360, namely Super users and normal users. Super users enjoy the admin privileges and have access to all modules. They can define the authorization for the different level of users. They restrict the access permissions for the normal users. The normal users will have minimal access permissions.
The normal users can be anyone from the organization, may be supported engineers, other non-BizTalk group members who are just monitoring BizTalk servers. They would not be aware of the conditions of the service instances. Hence, they cannot decide upon the action to be performed on the suspended instances as it’s a sensitive area like terminating/resuming the instances. This may lead to security and auditing problems also. When normal users configure Data Monitoring and try to resume a suspended instance, they may get an exception message as follows-
System.Exception: User does not have enough rights to access the BizTalkQueryService(service) and ExecuteServiceInstanceOperation(operation).
The administrator alone can know the state of the instances and decide upon the action on them. For this reason, BizTalk360 has provided the restriction that only superusers can perform the resume/terminate action for them.
An in-depth analysis on the super user access to terminate instances:
Let’s have an in-depth look into this limitation and how it must be handled. The user logged into BizTalk360 may be a super user. But still, that user will not be able to perform any action on the service instances. Do you know why? Let’s move forward to know the reason.
When we install BizTalk360, we provide the service account credentials. This service account will be the user who is running the App Pool and monitoring service. The logged in user running the MSI to install BizTalk360 may be different from the service account. When the application is installed, the logged in user will be created as a superuser in BizTalk360 by default.
So, what happens to the service account if it’s different from the logged in user?
The service account running the IIS App pool and the monitoring service must be created as the “Super User” in BizTalk360. Only then this user can perform the resume/terminate actions on the service instances. Otherwise, the above exception will be thrown.
Since these are sensitive operations on the instances, only the super user/ administrator should be able to perform such tasks. Therefore, BizTalk360 has imposed this restriction that only when the service account is added as the super user, he can perform the operations on the suspended service instances.
Author: Praveena Jayanarayanan
I am working as Senior Support Engineer at BizTalk360. I always believe in team work leading to success because “We all cannot do everything or solve every issue. ‘It’s impossible’. However, if we each simply do our part, make our own contribution, regardless of how small we may think it is…. together it adds up and great things get accomplished.” View all posts by Praveena Jayanarayanan
by Praveena Jayanarayanan | Jul 4, 2017 | BizTalk Community Blogs via Syndication
BizTalk360 is a single platform to have total control over your BizTalk environment. It has the three main modules namely Operations, Monitoring and Analytics. Monitoring is considered as the main feature of BizTalk360 because it provides rock solid monitoring for the BizTalk environment and informs us via email alerts when the BizTalk server is suffering from problems and downtimes.
As per the below quotes,
“Listening to our customer’s feedback makes them feel appreciated and part of the value creation process”,
We always listen to their valuable suggestions and feedback and add them to BizTalk360 in every upcoming release. We also make enhancements to the existing features based on the customer feedback. This blog explains about one such enhancement on actions performed on the suspended instances.
MessageBox Queries Monitoring:
Data Monitoring was one such feature included in BizTalk360, from the customers’ feedback. Data monitoring helps to monitor the send/receive ports, service instances and exception data from different data sources in BizTalk server. Message Box Queries monitoring is a part of Data Monitoring which is used to monitor the service instances. The service instances may be running or may get suspended in BizTalk servers due to various reasons.
The messaging service instance is the service instance that’s created for your receive and send port at the run time. A receive port/send port is a combination of various things. Ex: An adapter (File, WCF, SQL etc.), a receive pipeline (and a send pipeline if two-way), and Maps. They get instantiated like the objects for the classes and have different states in their lifetime namely,
- Ready to Run
- Scheduled
- Dehydrated
- Suspended (Resumable)
- Suspended (Non-Resumable)
- Active
- In Breakpoint
Here in monitoring, we can monitor the count of these instances at various stages and the alerts will be triggered based on the filters and threshold value configured. It is important to monitor the number of service instances, to keep the BizTalk environment healthy. Having many instances will make the MessageBox database bloated which in turn will affect the performance of the environment. The service instance count can be retrieved from BizTalk Administrator group hub page which displays only the count and does not tell you if it’s the expected count or not. A person seeing this information needs to be a BizTalk expert to understand the various states. Here comes our MBQ monitoring which alerts users according to the threshold limit configured. A non-BizTalk person can now easily understand the alert message and act accordingly.
Actioning on the suspended service instances:
Based on the state of the service instances, the administrator can decide on whether to resume or terminate the instances. For example, when a message is sent through the send port and if it’s stopped, then the instance gets suspended. Once the send port is up, the message can be resumed and processed. Instead of going to the BizTalk admin console and checking it, BizTalk360 has the feature to terminate/resume the instances from the monitoring itself. We can also configure the time when we want to perform the action, either every time or during Error/Warning condition.
So, what happens when Action Required is ticked?
There may be scenarios wherein, the customer wants to monitor any suspended messages that by the end of the day are no longer relevant and should be terminated. So, in this case, BizTalk360 can automatically terminate the instances as per the alarm configuration. This can avoid the excess workload to the BizTalk user as he needs to go and manually run the query to find the instances and action it. We also have the option to bulk terminate the suspended instances altogether instead of doing one by one. There is also an archiving option and to download the instances.
Can non-super users terminate/resume suspended instances?
We have two kinds of users in BizTalk360, namely Super users and normal users. Super users enjoy the admin privileges and have access to all modules. They can define the authorization for the different level of users. They restrict the access permissions for the normal users. The normal users will have minimal access permissions.
The normal users can be anyone from the organization, may be supported engineers, other non-BizTalk group members who are just monitoring BizTalk servers. They would not be aware of the conditions of the service instances. Hence, they cannot decide upon the action to be performed on the suspended instances as it’s a sensitive area like terminating/resuming the instances. This may lead to security and auditing problems also. When normal users configure Data Monitoring and try to resume a suspended instance, they may get an exception message as follows-
System.Exception: User does not have enough rights to access the BizTalkQueryService(service) and ExecuteServiceInstanceOperation(operation).
The administrator alone can know the state of the instances and decide upon the action on them. For this reason, BizTalk360 has provided the restriction that only superusers can perform the resume/terminate action for them.
An in-depth analysis on the super user access to terminate instances:
Let’s have an in-depth look into this limitation and how it must be handled. The user logged into BizTalk360 may be a super user. But still, that user will not be able to perform any action on the service instances. Do you know why? Let’s move forward to know the reason.
When we install BizTalk360, we provide the service account credentials. This service account will be the user who is running the App Pool and monitoring service. The logged in user running the MSI to install BizTalk360 may be different from the service account. When the application is installed, the logged in user will be created as a superuser in BizTalk360 by default.
So, what happens to the service account if it’s different from the logged in user?
The service account running the IIS App pool and the monitoring service must be created as the “Super User” in BizTalk360. Only then this user can perform the resume/terminate actions on the service instances. Otherwise, the above exception will be thrown.
Since these are sensitive operations on the instances, only the super user/ administrator should be able to perform such tasks. Therefore, BizTalk360 has imposed this restriction that only when the service account is added as the super user, he can perform the operations on the suspended service instances.
Author: Praveena Jayanarayanan
I am working as Senior Support Engineer at BizTalk360. I always believe in team work leading to success because “We all cannot do everything or solve every issue. ‘It’s impossible’. However, if we each simply do our part, make our own contribution, regardless of how small we may think it is…. together it adds up and great things get accomplished.” View all posts by Praveena Jayanarayanan
