Can I get few real time scenarios for using Network zone to its full. Also I want points justifying if its good to have or must to have configuration in a managed implementation.
We have implemented Network Zones in multiple customer places and it is a good practice to have this and especially when we are deploying for large environments I would say it is a must have feature to prevent OneAgent communication to travel across multiple DCs. Let's say you have customer with less then 500HUs and 100 servers spread across 2 DCs then I would also recommend Network Zones to be configured for better OneAgent communication routing. It is more of a best practice rather than must have feature.
Here your last comment say its a best practice means a good to have feature but I want real time debate over this, can you provide me few reasons where network zones configuration are redundant or not required to setup due to which any customer decided not to set it up in their monitoring instances. I believe we should actually make network zones configuration as mandatory field. What say lets have a open debate over this? you can select any side of the topic?
Debate? That sounds interesting, @techean. I am up for it. See I am not opposite to make Network Zones as mandatory feature. I feel there are 2 aspects why it is not mandatory and a best practice.
1. If the deployments are small, let's say 50 HUs. Then the recommendation is to have a AG and one more for DR. In such cases there will only be one DC/single location. This means there is no need for Network Zones to be included.
2. Since it his not mandatory, customers don't even think about creating Network Zones as the education about it is less. Moreover, it is still in preview mode not introduced as GA. Based on the feedback from customers, they will move it to GA.
As per my experience there is a UK customer who I worked with and their architecture is so good that they made it Network Zones mandatory after attending my vILT training last year. Now they have deployed more than 2000 HUs across their 2 DCs.
I want it a mandatory configuration irrespective of the HU consumed at any DC. As per the infrastructure network zone of any organization in a Production environment are as below
1) PROD DC REGION - PROD
2) NEAR PROD DC REGION - NPROD
3) NEAR DISASTER RECOVERY DC REGION - NDR
4) FAR DISASTER RECOVERY DC REGION - FDR
Now all host in the respective regions can be definitely custom tagged with this flag, but let us move one step further, consider all our agents in a prod region are monitoring hosts, at the same time agents on hosts NDR are disabled for monitoring. Dynatrace with single instance (clustered) can monitor all network zone hosts with just configuration. Disable oneagent monitoring for inactive zones. Switch monitoring to required zone only on the go. This will help to create unnecessary alerts in times of manual DR movement of monitoring applications.
This reminds me of one of the product ideas that I have read, Having a feature to disable monitoring of hosts directly via host group wise. Product team can also implement the option to disable monitoring or setting maintenance windows based on Network Zones.
Being Consultants and Architects, it will become especially architect's opinion to suggest network zones to customers. I strongly recommend this instead of making this as a must have feature. I get it where you are coming from, customers from our place don't do it until it is mandatory but if we think world-wide, most of customers want to always follow best practices.
Network Zones are critical for Managing Oneagent communication. For Example, Lets say you have ONPrem and a Cloud Service Provider for your infrastructure. The Dynatrace Oneagents could talk to any activates they can reach out to, But if you have Network Zones in place it instructs the Agents on the hosts you have set a Network Zone to talk to a specific Group of AGs. This allows you to isolate traffic, so all AWS hosts talk to a AWS set of AGs, and All Onprem Hosts talk to a set of AGs designated for OnPrem Communication.
This was a simple example but can be expanded to larger organizations where you'd want to keep communication isolated and grouped together.