Best Practice Deployment Guide - amasol AG · This Best Practice Deployment Guide is intended to...
Transcript of Best Practice Deployment Guide - amasol AG · This Best Practice Deployment Guide is intended to...
Confidential: Distribution limited to Dynatrace, Ixia, and their customers and channel partners. Document No.: 915-6958-01, Rev B August 2015
Best Practice Deployment Guide
Dynatrace Data Center RUM using
Ixia Network Visibility Solutions
Confidential Page 2
CONTENTS
Executive Summary ...........................................................................................................................................................3
Target Audience ............................................................................................................................................................3
Guideline on THE USE OF a SPAN Port ...............................................................................................................................4
SPAN limitations ...........................................................................................................................................................4
Monitoring Challenges with Traditional Approach .............................................................................................................5
A Better Way. A Best-Practice Approach. .........................................................................................................................7
Key Ixia technologies .....................................................................................................................................................7
How Ixia supports typical DCRUM monitoring challenges ..............................................................................................8
Best Practice Deployment Examples................................................................................................................................10
Scenario 1: Single monitoring point per AMD .............................................................................................................10
Scenario 2: Multiple monitoring points, multiple tool environment ............................................................................11
Scenario 3: Multiple tenancy environment .................................................................................................................12
Scenario 4: Virtualized environment with physical tapping and monitoring ................................................................13
Scenario 5: Virtualized environment with virtual tapping and physical monitoring .....................................................14
Scenario 6: Virtualized environment with NFV monitoring..........................................................................................15
Why Partner with Ixia .....................................................................................................................................................16
Appendix A: Resources ...................................................................................................................................................17
From Ixia .....................................................................................................................................................................17
From Dynatrace ..........................................................................................................................................................17
Appendix B: Virtual Tap Connectivity..............................................................................................................................18
Deployment Strategies ................................................................................................................................................18
Appendix C: Fiber Tap Connectivity ................................................................................................................................21
Fiber Splitters ..............................................................................................................................................................21
Correct Connections....................................................................................................................................................22
Incorrect Connections .................................................................................................................................................22
Glossary ..........................................................................................................................................................................24
Confidential Page 3
EXECUTIVE SUMMARY
This best-practice document draws on industry trends and lessons learned to enable the Dynatrace Data Center RUM
(DCRUM) sales cycle and avoid technical pitfalls. In this document, we want to leverage Ixia’s Network Visibility
Solutions to proactively:
Accelerate and de-risk PoCs
o Ensure capture environment is as clean and correct as possible
o Remove overburden on SPANs/Mirror that could affect switch performance
Remove technical constraints
o Contention with other packet capture devices
o Lack of SPAN/Mirror ports
o Monitoring in virtualized environments
Improve quality of commercial bids where traffic capture is a blocker
o A better overall solution vs. point product sell
Provide a migration path to hybrid and virtual environment monitoring
o Protect monitoring investment
o Monitor mixed environments
Unnecessary change control
o Leverage one-time tap installs to prevent SPAN reconfigurations
For most proof of concepts (PoCs), a SPAN port will be the best way forward as it is easier for the customer to set up (2
concurrent SPAN ports are available on most managed switches). Do keep in mind that SPANs have a couple of
architectural limitations. The main issue is that the monitoring device (AMD) may miss packets due to port over-
subscription (sending many VLANs to one SPAN port or a very highly utilized link to one SPAN). This might not be an
issue during the PoC where a certain traffic loss might be acceptable, but during implementations and specific scenarios
it is good to understand that there are other techniques that can help you overcome some of these limitations when
necessary.
Target Audience
This Best Practice Deployment Guide is intended to assist Dynatrace employees and partners in planning, deploying,
and managing Dynatrace DCRUM solution. This document highlights key considerations to avoid pitfalls, operational
challenges, and customer constraints by leveraging Ixia’s Network Visibility Solutions.
Confidential Page 4
GUIDELINE ON THE USE OF A SPAN PORT
To enable an application performance management (APM) system to evaluate end user experience data, it is necessary
to passively listen to the in-flight networked application data. Switched port analyzer (SPAN) ports is one of the ways of
getting this kind of data, they occur at the switch and do not require additional hardware. The network administrator
simply configures one port on the switch to serve as a SPAN port, and the switch then delivers copies of all traffic from
any port on the switch to the SPAN port, allowing for the connection of a monitoring device. This is very common during
POC’s as it is most of the time easy to set-up.
SPAN limitations
SPAN is not all bad but one must be aware of its limitations and since managed switches are integral part of the
infrastructure, one must be careful not to establish a failure point. Understanding what can be monitored is important
for success since SPAN ports are often oversubscribed leading to drop frames.
Enabling SPAN for multiple interfaces or VLANs is not recommended. This SPAN’ing of mass ports is always dangerous
and likely to cause issues in terms of data integrity as well as back pressure buffering issues in addition to over
subscription of the listening destination port.
Dynatrace DCRUM can and does successfully use SPAN as an access technology. As long as it is looking for bandwidth
application-layer events within the boundaries of the destination SPAN port, for example “specific conversation
analysis”, “specific application flows” and for access to pre filtered traffic, etc.
These monitoring requirements manage the amount of bandwidth and so oversubscription is less of an issue. The reason
for their success is that it keeps within the parameters and capability of the SPAN port capability. In other words, a SPAN
port is a very usable technology if used correctly.
When deciding whether to use a tap or SPAN, the two primary factors that will affect your decision are the type of
analysis and amount of bandwidth/interfaces you need to monitor.
A SPAN port performs well on low-utilized networks, limited numbers of source interfaces, or when monitoring is not
affected by dropped packets.
A tap is ideal if network utilization or number of source interfaces is moderate to heavy.
Confidential Page 5
MONITORING CHALLENGES WITH TRADITIONAL APPROACH
The following list of typical problem areas can prevent successful DCRUM POC’s, technical designs/implementations,
commercial bids, and unnecessary support calls. The remainder of this Best Practice Deployment Guide shows proactive
mitigation steps leveraging Ixia’s Network Visibility Solutions.
Table 1: Typical DCRUM monitoring problems
Problem Areas Problem Details
Virtual Environments How to monitor in VMware environments
How to monitor in Cisco Nexus environments
How to monitor in cloud environments
How to monitor in hybrid networks
AMD Connectivity No available SPAN or tap points for the AMD
Need to coexist with security or other monitoring tools
Mix of network link speeds (1G, 10G, 40G, 100G)
High speed links
Traffic Too much traffic
Duplicate packets
Encrypted packets
No NetFlow capabilities in network
Encapsulated traffic types (e.g. MPLS, VNTag, GRE)*
East-west traffic contained within a virtual host
Privacy Multi-tenant deployments
Commercially sensitive / private traffic
High Availability Missing traffic
SPAN ports unreliable under network stress
Commercial Need multi-tiered monitoring with limited budget
Don’t want to lose investment in existing tools
Migration path from physical to virtual monitoring
Need a complete single solution
*This isn’t a problem for the AMD but will help to offload some of the processing
IMPORTANT: For encrypted traffic it might be critical that packets don’t get lost as the AMD will not be
able to decrypt the information. This is certainly the case in environments where a user session is only
established once or twice a day (i.e., Citrix in combination with SAP SNC). In this case the use of a tap will
be necessary to see each packet.
Confidential Page 6
Figure 1: Traditional DCRUM data collection
Figure 1 shows the traditional data collection points in a DCRUM deployment. The AMDs monitor traffic directly from
network switch SPAN or Mirror Ports before processing information for the Advanced Diagnostics Server (ADS) and
Central Analysis Server (CAS).
Connecting AMDs to SPAN or Mirror ports has considerable shortcomings:
1) Monitoring traffic robustness. SPAN or Mirror ports are unreliable, leading to scenarios of missing or duplicate
traffic, particularly when the network is under load; and missing traffic, particularly when encrypted, prevents
DCRUM from properly doing analytics
2) SPAN shortages with contention between existing security and performance monitoring tools
3) Difficulty in extracting monitored traffic from virtualized environments
CAUTION: SPAN or Port Mirroring can have a negative impact on the
source production traffic if run in consistently high load configurations.
Oversubscription can also cause data integrity issues on the AMD.
Central Analysis Server (CAS)
Advanced Diagnostics
Server (ADS)
Agentless Monitoring Device (AMD)
The Internet
Routers Core Switches
Web Servers
App Servers
Database Servers
End User
Confidential Page 7
A BETTER WAY. A BEST-PRACTICE APPROACH.
Key Ixia technologies
Ixia’s Network Visibility Solutions enable resolutions to the previous list of Problem Areas listed in Table 1: Typical
DCRUM monitoring problems on page 5.
Here we introduce the key technologies to overcome these Problem Areas.
Tap
Ixia taps provides 100% visibility and permanent passive access points into the customer’s network. When a monitoring
tool is needed, simply connect the device to the tap instead of taking down the link and interrupting traffic. Taps pass all
network traffic—including Layer 1 and 2 errors—without introducing bottlenecks or points of failure.
vTap (Virtual Tap)
Ixia's Phantom Virtualization Tap™ bridges the physical and virtual, so
that you can monitor the virtualized network with your existing set of
tools. Phantom is capable of capturing and then sending inter-VM traffic
of interest to the tools that are already monitoring your physical
network.
Figure 3: Ixia vTaps bridge physical and virtual environments
Figure 2: Ixia taps provide 100% visibility of network traffic
Confidential Page 8
NPB (Network Packet Broker)
Provides complete visibility by intelligently connecting your network with monitoring tools to aggregate, filter, load
balance and de-duplicate network traffic. The Ixia NTO offers an easy-to-use, drag-and-drop management interface that
makes configuration a lot easier.
Figure 4: Ixia NTO network packet brokers ensure each monitoring tool gets the right data at the right time
How Ixia supports typical DCRUM monitoring challenges
Table 2 looks at the ways Ixia’s Network Visibility solutions help you get over typical monitoring challenges in both
physical and virtual environments.
Table 2: Solutions to typical DCRUM monitoring problems
Problem Areas Problem Details How Ixia helps
Virtual Environments
How to monitor in VMware environments
Ixia’s vTap (Phantom Tap) allows for selected inter-VM traffic to be extracted from VMware Hypervisors and forwarded to AMDs.
How to monitor in Cisco Nexus environments
Ixia’s physical and virtual (Phantom Tap) taps allow for traffic to be extracted from physical links and the hypervisor and forwarded to the AMDs.
How to monitor in cloud environments
Ixia’s virtual tap (Phantom Tap) enables monitoring in virtualized cloud environments
How to monitor in hybrid networks
Ixia’s virtual tap (Phantom Tap) enables monitoring in virtualized cloud environments while Ixia’s physical taps and network packet brokers (NPB’s) allows for monitoring in physical networks
AMD Connectivity
No available SPAN or tap points for the AMD
Ixia taps allow for reliable monitoring of physical links. Ixia NPBs allow for traffic replication of existing SPAN or taps to multiple tools. The NPBs also allow for filtering and/or load balancing amongst tools to ensure the right traffic is forwarded to the right tools.
Need to coexist with security or other monitoring tools
Ixia NPBs allow for sharing of traffic amongst many tools to ensure the right traffic is forwarded to the right tools, removing unwanted traffic and removing sensitive payloads (where required).
Mix of network link speeds (1/10/40G/100G)
Ixia NPBs can aggregate various link speeds and forward to AMDs across 1/10/40G with the option of load balancing, filtering, and de-duplication.
High speed links Ixia taps + NPBs can extract traffic across high-speed links (e.g. 100G), filter out what is not needed and forward across slower links to an AMD, with the option of load balancing, filtering, and de-duplication.
Confidential Page 9
Problem Areas Problem Details How Ixia helps
Traffic Too much traffic Ixia NPBs prevent oversubscribing AMDs by load balancing, filtering, and de-duplication.
Duplicate packets Ixia NPBs can remove duplicate packets if not needed by the AMDs. This offloads unnecessary processing and makes the AMDs more efficient.
No NetFlow capabilities in network device/or offload NetFlow from core device
Ixia next-gen ATIP NPBs can generate NetFlow statistics and forward to the AMDs (collectors).
East-west traffic contained within a virtual host
Ixia virtual tap (Phantom Tap) allows for selected inter-VM traffic to be extracted from VMware Hypervisors and forwarded to AMDs.
Multi-tenant deployments Ixia NPBs can separate customer traffic and forward to separate tools for “data segregation.”
Commercially sensitive / private traffic
Ixia NPBs can filter out sensitive traffic and remove sensitive payloads before forwarding to tools for analysis. Ixia ATIP NPBs can mask sensitive data in the payload.
Privacy Missing traffic Ixia Taps allow for traffic capture on multiple segments that can be aggregated with Ixia NPBs before forwarding to AMDs for full visibility.
SPAN ports unreliable under network stress
SPAN or mirror ports can be unreliable, particularly under network stress. Ixia taps ensure full packet capture regardless of network stress.
High Availability
Need multi-tiered monitoring in dynamic or physically challenged environments
Ixia NPBs allow for traffic to be aggregated and cleaned from multiple tiers and sent to a single AMD. This can make it easier to manage which traffic needs to be seen by the AMD, although the AMD is also able to use multiple NIC’s.
Don’t want to lose investment of existing tools
Ixia NPBs allow existing and new tools to coexist. For instance, business-critical applications can be sent to DCRUM while the rest is sent to the preexisting tools (e.g. NPM, Security).
Commercial Migration path from physical to virtual monitoring
Ixia taps allow for extracting traffic from both physical and virtual environments, including a combination of the two. Physical AMD investments can be preserved even as the customer migrates from a physical- to hybrid- and virtual-environments without losing the quality of reporting.
Need a complete single solution
Dynatrace’s DCRUM with Ixia’s Network Visibility Solutions provide design guidance and proven interoperability.
Caution: SPAN and Mirror Ports should be used appropriately and within context in production
networks. Network Taps are a common best practice to ensure a robust DCRUM solution.
Confidential Page 10
BEST PRACTICE DEPLOYMENT EXAMPLES
Scenario 1: Single monitoring point per AMD
Description To ensure reliable traffic capture, Ixia’s network taps forward an exact replication of traffic from optical or copper links to the AMD
Benefits 1) Guaranteed robustness and clean traffic by not using SPAN / Mirror ports
2) Get around contention for SPAN / Mirror ports
Figure 5: Ixia network tap directly feeding an AMD
Customer Network DCRUM
Switch
Switch
Agentless Monitoring Device
(AMD)
Tap
Confidential Page 11
Scenario 2: Multiple monitoring points, multiple tool environment
Description To ensure reliable traffic capture, Ixia’s network taps forward an exact replication of traffic from optical or copper links to the AMD.
Benefits 1) Guaranteed quality traffic by not using SPAN / Mirror ports
2) Get around contention for SPAN / Mirror ports
3) Monitor different link speeds
4) Aggregate and clean traffic from multiple network providers into one AMD
5) Share traffic to other tools, i.e. “Get the right traffic to the right tool”
6) Offload unnecessary AMD processing by removing duplicate packets
7) Co-exist with multiple destination tool types
Figure 6: Best practice monitoring in a multi-tool environment
Confidential Page 12
Scenario 3: Multiple tenancy environment
Description Enable multi-tenancy monitoring when customer traffic uses the same physical links
Benefits All the benefits of the earlier scenarios, plus:
1) Separates customers traffic when seen in a shared network environment
a. By MPLS label, VLAN, GRE, and other custom fields
b. By IP address (source or destination)
2) Choose which AMDs to send data
Figure 7: Multi-tenancy monitoring
Confidential Page 13
Scenario 4: Virtualized environment with physical tapping and monitoring
Description It is sometimes possible to monitor virtualized environments with physical monitoring infrastructure. Physical taps can extract traffic from fabric links, while Ixia NPBs remove tag headers, aggregate from multiple points, and distribute traffic to AMDs and other probes as needed.
Ixia and Dynatrace have a proven working solution with Cisco Nexus environments.
Benefits 1) A way to physically monitor virtualized environments
2) Removes contention issues with other tools
3) A scalable solution where more AMDs can be added as traffic rates increase
Figure 8: Physical taps in a Nexus environment
Confidential Page 14
Scenario 5: Virtualized environment with virtual tapping and physical
monitoring
Description Ixia virtual taps enable monitoring of virtual traffic by physical AMDs. This also allows for hybrid network monitoring when combined with physical taps and NPBs.
Benefits 1) A way to monitor virtualized environments
2) Continued monitoring even as VMWare’s vMotion moves VMs to other physical hosts; Ixia virtual taps follow the sessions, ensuring continuous monitoring.
3) A migration path to hybrid network monitoring
4) Removes contention issues with other tools
Figure 9: Virtual and physical taps
Confidential Page 15
Scenario 6: Virtualized environment with NFV monitoring
Description Elastic cloud deployments require a fully virtualized monitoring infrastructure, with NFV instances of taps, NPBs, and AMDs; allows cloud and service providers to offer a fully managed global monitoring solution.
Note: Ixia’s capabilities are quickly evolving in the NFV space. Please contact Ixia for the latest updates.
Benefits 1) Extends the monitoring benefits of the physical world to the virtual world, with solutions to the problems listed in
2) Table 1
3) Scale as needed – “spin up, spin down”
Figure 10: Fully virtualized monitoring environment with NFV instances of taps, NPBs, and AMDs
Confidential Page 16
WHY PARTNER WITH IXIA
The Ixia advantage:
Easy to work with; will support your PoC, design, and deployment questions.
Easy to deploy and configure with intuitive NPB GUI (see Figure 11)
Robust – NPB’s fully non-blocking architecture ensures we don’t drop packets
Enables monitoring in physical, hybrid, and virtual environments
Global partner with regional presence and support
Figure 11: View of Ixia's intuitive NPB GUI
For more information or to request Ixia support: http://info.ixiacom.com/dynatrace.html
Confidential Page 17
APPENDIX A: RESOURCES
From Ixia
Visibility Solutions Webpage http://www.ixiacom.com/solutions/visibility-architecture
Physical Taps http://www.ixiacom.com/products/ixia-net-optics-network-tap
Virtualized Taps http://www.ixiacom.com/products/virtual-tap
NPBs (Net Tool Optimizers) http://www.ixiacom.com/products/net-tool-optimizers
ATIP – Application Threat Intelligence Processor for Intelligent Packet Forwarding
http://www.ixiacom.com/products/application-and-threat-
intelligence-processor
PoC Demo Gear Request and Video Overview http://info.ixiacom.com/dynatrace.html
Optical Tap Split Ratio Calculator App, ixSplitZ Google Play
From Dynatrace
DCRUM Product Page http://www.dynatrace.com/en/products/data-center-real-user-monitoring.html
DCRUM Case Study https://info.dynatrace.com/apm_dcrum_ent_cs_west_best_mutual_fulfillment.html
Network Application Performance Management eBook
https://info.dynatrace.com/apm_dcrum_eb_network-application-performance-management_en_registration.html
Confidential Page 18
APPENDIX B: VIRTUAL TAP CONNECTIVITY
Deployment Strategies
vTap is deployed in the Host hypervisor environment. During the deployment, you will need to take steps to (1) create a
dedicated vSwitch and vNIC for the tapped traffic and (2) specify the encapsulation method of either VLAN for local
access and GRE for remote tools. GRE is the most flexible option and is the recommended transport mechanism.
Method 1 – Direct connect to monitoring tool
Fine for small deployments with local tool
Create dedicated VLAN or GRE for monitoring traffic; keep in mind that the AMD at this point in time cannot
terminate the GRE tunnel so this will need to be done differently
Filtered traffic required to avoid tool and network overload
Separate vSwitch and NIC for monitoring traffic is STRONGLY RECOMMENDED (avoids conflict with production
traffic)
Phantom vTap can be configured to monitor any VM within the host. Multiple filters (policies) than can be
created on the tapped data and sent to a single or multiple Dyantrace tools
Figure 12: Method 1 – direct connect
Confidential Page 19
Method 2 – Advanced features and scaling with NPB
For larger deployments with local tool(s)
Create dedicated GRE tunnel & vSwitch for monitoring traffic
Connect GRE to NPB and distribute traffic
Advanced traffic filtering recommended; available from network packet broker
Separate NIC for monitoring traffic is STRONGLY RECOMMENDED (avoids conflict with production traffic)
Figure 13: Method 2 – through network packet broker
Confidential Page 20
Filtering and NPB functions
The Ixia Phantom vTap provides more than tap capabilities. L2/L3/L4 filter policies can be created and applied and
directed to multiple tools destinations. HTML user interface provides the mechanism of choosing:
Which VM or VMs to tap
Where to send the tapped data
Transport over VLAN or GRE for local or remote tools
Defining a single or multiple L2/L3/ L4 filtering policy to each VM that is tapped
Figure 15: L2/L3/L4 filtering
Confidential Page 21
APPENDIX C: FIBER TAP CONNECTIVITY
Following is information on the proper way to connect Ixia Fiber Taps and how to avoid common tap connection
problems.
Fiber Splitters
A Net Optics Fiber Tap is designed with fiber optic splitters. The most important thing to understand is that a fiber optic
splitter is directional, and the installation requirements of the tap are based upon the splitter’s requirements.
Refer to diagram 1, which shows one strand of fiber. When connected properly, light will flow from A’s TX port to the
Splitter, which splits the light to B’s RX port and C’s RX port.
Diagram 1
Note: Red lines in the diagrams signify the light that transverses the fiber; black lines indicate dark fiber (no light, no
traffic).
Refer to diagram 2, which also shows a single strand of fiber. When connected INCORRECTLY, light will flow from B’s TX
port to A’s RX port but not to C’s RX port. This is because light can only follow the fiber, even if it is curved or coiled, but
cannot change directions. Therefore the light cannot flow from B’s TX port to the splitter and then change direction to
C’s RX port, which will remain dark. Even though this connection is incorrect, the link between device A and B will be up
and functioning, but the device connected to C will not receive any traffic.
Diagram 2
These examples show that you must know which side of the fiber from a device is TX and has light, and which is RX and
is dark. Most devices are labeled TX and RX, but patch panels are rarely labeled, requiring you to determine which side
has the light.
WARNING: Do NOT look into the end of the fiber pair to see which is lit, because doing so may cause eye damage.
Confidential Page 22
The following diagrams are intended to show the many ways a Net Optics Fiber Tap can be connected. Only the first one
will work, but the others will lead you to believe the device is functioning correctly.
NOTE: Do not be concerned as to what the devices A and B are. They may be switches, routers, firewalls, servers, patch
panels, and so on. No matter what the device may be, fiber is connected as a pair of strands. One strand is TX and carries
the light. The other strand is RX, and it is dark until its other end is connected to a TX port on another device.
Correct Connections
Diagram 3 shows the CORRECT connectivity for a tap.
Device A’s TX is connected to the tap’s RX on Port A. The light passes through the tap to the splitter, where it is
split to one TX of the tap monitor port as well as the tap’s TX on Port B. The tap’s Port B TX is connected to
Device B’s RX.
Device B’s TX is connected to the tap’s RX on Port B. The light passes through the tap to the splitter, where it is
split to the other TX of the tap monitor port as well as the tap’s TX on Port A. The tap’s Port A TX is connected to
Device A’s RX.
Diagram 3 Correct connectivity
Incorrect Connections
Now let’s look at the INCORRECT ways a tap can be connected.
Diagram 4 shows the most common error made in the connection of a tap. Device A’s TX is connected to the tap’s Port
A TX. The light passes through the tap to its Port B RX and onto Device B’s RX, but since the light at the splitter is going
the wrong direction, no light is split to the Monitor Port TX. The same problem occurs with the light being passed from
Device B’s TX port.
Beware of this connection! Since the link from Device A to B is up and functioning, it gives the misleading impression
that the tap is not functioning properly. To fix this problem, the fiber from Device A to the tap must be flipped AND the
fiber from Device B to the tap must be flipped. Doing so will make the connection look like Diagram 3.
Tap
Confidential Page 23
Diagram 4 Incorrect connectivity
Diagram 5 and 6 are obviously bad connections Device A’s TX is connected to Device B’s TX. The light from each simply
collides, with no RX to receive it. These connections will not work at all.
To fix Diagram 5, you must flip the fiber from Device A to the tap.
To fix Diagram 6, you must flip the fiber from Device B to the tap.
Diagram 5 Incorrect connectivity
Diagram 6 Incorrect connectivity
Tap
Tap
Tap
Confidential Page 24
GLOSSARY
AMD (Agentless Monitoring Device)
Dynatrace’s Agentless Monitoring Device (AMD) is a network traffic monitoring device attached to mirrored ports of the core switches or to network tap devices. From this vantage point, AMD discovers all protocols, servers, ports, and users on the network and analyzes IP and non-IP traffic.
ATIP (Application and Threat Intelligence Processor)
Ixia’s Application and Threat Intelligence (ATI) Processor delivers real-time application data to monitoring tools so that customers can be empowered to make better decisions with better data. It provides rich data on behavior and location of users and applications, in any format needed – raw packets, filtered packets, or metadata. This allows IT teams to identify unknown network applications, mitigate network security threats from suspicious applications and locations, and spot trends in application usage to predict and forestall congestion.
CAS (Central Analysis Server) or
ADS (Advanced Diagnostics Server)
Dynatrace’s report server is the part of the Data Center Real User Monitoring (DCRUM) responsible for measurement data processing, storage, and report generation. It connects to one or more AMDs and processes the measurement data into a relational database of measurements. The database is then used to serve interactive reports to the DCRUM system user.
DCRUM (Data Center RUM) Dynatrace’s DCRUM passively collects network traffic, supporting the auto-discovery of all applications, servers, and clients on the network. Analysis is performed on transactions, application usage, end-user experience, and more.
NPB (Network Packet Broker) Ixia’s suite of Network Packet Broker solutions helps optimize and secure rapidly evolving, dynamic data centers. Residing between monitoring tools and networks themselves, these advanced resources perform intelligent, dynamic aggregation and filtering of network traffic before it reaches the tool farm.
Ixia's patented three-stage filtering technology efficiently performs:
Packet conditioning
Load balancing
Packet shaping
Packet trimming
Packet deduplication
NVS (Network Visibility Solutions) Ixia’s Visibility Architecture is built on the industry’s most comprehensive network visibility product portfolio. This portfolio, serving as the foundation of the Visibility Architecture, includes network access solutions, network packet brokers, application and session visibility solutions, and an integrated management platform.
The portfolio provides enterprises and service providers with a single integrated resource to address all of their visibility needs.
Confidential Page 25
SPAN (Switched Port Analyzer) or
Mirror Port
A dedicated port a network switch used to send a copy of network packets seen on another switch port (or an entire VLAN). This is commonly used for network appliances that require monitoring of network traffic such as an intrusion detection system, passive probe, or real user monitoring (RUM) technology that is used to support application performance management (APM)
Tap Ixia’s Net Optics family of taps provides 100 percent visibility and permanent passive access points into the customer’s network. When a monitoring tool is needed, simply connect the device to the tap instead of taking down the link and interrupting traffic. Taps pass all network traffic—including Layer 1/2 errors—without introducing bottlenecks or points of failure. Regardless of interface or location in the network, we provide a tap solution, supporting copper, multi-mode, and single-mode fiber at speeds up to 100Gbps with media conversion models available.
Taps can be deployed on any inline connection throughout the network, providing permanent access to network traffic and allowing total traffic visibility for network monitoring and security devices.
vTap (virtual TAP) Ixia's Phantom Virtualization Tap™ bridges the physical and virtual, so that you can monitor the virtualized network with your existing set of tools. Phantom is capable of capturing and then sending inter-VM traffic of interest to the tools that are monitoring your physical and virtual networks.
Phantom vTaps provide 100% visibility of traffic passing between virtual machines (VMs) in virtualized computing environments and clouds. These versatile software devices also send monitored traffic in encapsulated tunnels to physical monitoring tools, so you can use your existing tools and infrastructure to monitor your virtual environment.