cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
The Analytics Application included with Pulse Services Director offers a unique Table View in the Explore functions.
View full article
The Pulse Services Director vADC Analytics Application is intended to be both accessible and intuitive to use, with powerful graphic visualizations and insights into the traffic flows around your application. 
View full article
The Analytics Application included with Services Director displays a number of different types of metrics. The process by which metrics are generated and displayed varies between different types of graph, but the metric definition itself remains constant.
View full article
Pulse Virtual Traffic Manager v18.1 has introduced plugin-based Service Discovery that shipped bundled with two plugins: for Google Cloud, and for DNS.   The included DNS plugin was designed to help with a specific use case, where an authoritative DNS server returns a *subset* of the records every time it is queried, instead of the full set of records.   An example of this is AWS Route53 serving A-records for a large Elastic Load Balancer (ELB). Route53 will return up to 8 healthy records. This means that for ELBs with more than 8 nodes DNS query will only ever return 8, which a non-authoritative DNS server will cache and return for all subsequent queries.   If a regular DNS resolver is used to populate vTM pool nodes, this Route53 behaviour may lead to excessive vTM pool node churn. Additionally, traffic will only be ever sent to a maximum of 8 nodes.   To work around this issue, the bundled DNS plugin implements the following behaviour:   - For the hostname specified, find the authoritative DNS server(s) - Send a query for hostname's A-records directly to the discovered authoritative DNS servers - Cache the received results, along with each record's TTL - Check the cache for any existing records with TTL that hasn't expired - Combine the new records with the cached records, and return that superset as the result for vTM to use.   This behaviour has a side effect for some publicly registered domains with name servers that can't resolve the records within the domain, such as internally used domains. In this case, DNS resolver plugin will fail to work because in the process of discovering authoritative DNS servers upper level domain servers will respond with nameservers that can't resolve the names in question.   To work around this situation, DNS plugin can be run with an option "--nameservers" with IP address(es) of the internal authoritative DNS servers for the internal domain. This will bypass the logic for authoritative nameserver discovery.
View full article
The Virtual Traffic Manager is often used as an application delivery controller which passes HTTP traffic to backend nodes using the Apache HTTP Server. This guide aims to provide some general advice on tuning such a deployment. Virtual Server Configuration   A virtual server passing traffic to Apache backends can use a number of protocols including HTTP, Generic client first and SSL (if the website uses HTTPS). Of all these protocols HTTP (with SSL Decryption enabled if HTTPS is used) will provide the best experience: Backend connections can be reused for different frontend connections. The traffic manager's builtin webcache can be used to cache static content to decrease latency and reduce backend load. The traffic manager can offer the HTTP/2 protocol on frontend connections even if the Apache version on the backends doesn't support it. TrafficScripts rules can inspect and change HTTP headers in both directions.   Backend Connection Management Traffic Manager The Traffic Manager offers two important per pool settings for controlling the connections to backend nodes: The configuration key max_connections_pernode controls how many concurrent connections will be created by a single traffic manager to a single backend node. Please note that the limit is enforced per single traffic manager and not for the whole in a cluster. In a clustered deployment the number of concurrent connections scale up with the the number of traffic managers using a backend node at the same time in an active active setup. Depending on the maximum number of concurrent connections that a single Apache instance can handle it can be advisable to adjust this setting accordingly to prevent overloading the backend nodes. Please refer to Apache Performance Tuning for more information on tuning Apache's connection limits. The configuration key max_idle_connections_pernode controls how many idle connections to a single backend the traffic manager will keep open. Keeping idle connections open will speed up handling further requests but will consume slightly more resources on the backends. For websites which handle a large number of concurrent, short lived HTTP requests increasing the number of allowed idle connections can reduce request latency and thereby improve performance. Apache By default Apache closes idle keep-alive connections after 5 seconds while the Traffic Manager will try to reuse them for up to 10 seconds (controlled by the global configuration key idle_connection_timeout). This can cause retries or even request failures when the Traffic Manager tries to reuse a connection at the exact moment when Apache decides to close it. To avoid this it is advisable to change Apache's timeout via the KeepAliveTimeout configuration directive to at least five second higher than the traffic manager's timeout. SSL Configuration   The Apache HTTP Server offers multiple loaded modules to add support for HTTPS. The most popular is mod_ssl which uses the OpenSSL TLS stack.   Using SSL Encryption on a pool configured on the traffic manager should work with the combination of Apache and mod_ssl without any specific tuning. The following adjustments might however help to improve performance. Traffic Manager Ensure the the client side SSL cache of the traffic manager is enabled. This cache will make sure that most SSL connections to the backend nodes use SSL session resumption which is considerably faster and consumes less CPU power on both the traffic manager and the backend node. The client cache is controlled via the ssl!client_cache!enabled config key and enabled by default. Ensure the the client side SSL cache of the traffic manager is size appropriately. It should be at least as large as the total of distinct nodes that the traffic managers connects to, across all pools, via SSL. The size can be adjusted using the config key ssl!client_cache!size which defaults to 1024. Ensure that TLS 1.2 is enabled and a ciphers based on AES_128_GCM_SHA256 (for example SSL_ECDHE_RSA_WITH_AES_128_GCM_SHA256) are enabled and preferred. These ciphers combine security with excellent performance, in particular on CPUs which support the AES-NI and AVX instruction sets. Apache In the unlikely case that the Traffic Manager SSL settings suggested above cause connection failures changing the mod_ssl configuration as suggested below should fix the problems:   SSLCipherSuite HIGH SSLProtocol all -SSLv3 The SSL session cache is also disabled in the Apache HTTP server by default although Linux distributions often enabled it in the distributed configuration file. Please refer to the documentation of the SSLSessionCache configuration directive for information how to enable and size the session cache.   For optimal performance is also advisable to use a Linux distribution which ships version 2.4 or newer of the Apache HTTP server and OpenSSL version 1.0.2 or newer (for example Debian 9 or newer or Ubuntu 16.04 or newer).  
View full article
The Analytics Application included with Pulse Services Director operates on a dataset which is made from individual records, each of which describes a single  transaction
View full article
The Pulse Services Director makes it easy to manage a fleet of virtual ADC services, with each application supported by dedicated vADC instances, such as Pulse Virtual Traffic Manager. This table summarises the compatibility between supported versions of Services Director and Virtual Traffic Manager.
View full article
 Getting Started with Pulse vADC Welcome to Pulse Secure Application Delivery solutions! This article gives a quick five-step guide to how you can download Pulse Virtual Traffic Manager, including how to download the Developer Edition of the software, installing and configuring your first services, and then how to request a full-performance 30-day license key to experience the full power of Pulse Application Delivery solutions.   1. Download Pulse vADC The quickest way to get started with Pulse vADC is to  download the Developer Edition  of Pulse Virtual Traffic Manager. This will give you access to all the features and full programmability of Pulse vADC software, including add-on options for web application firewall (WAF) and web content optimization (WCO). The software needs no license key, but is limited to 1 Mbps/100 SSL tps throughput, so it can be used to explore the software and develop applications and interfaces.   2. Install Pulse vADC Grab either the Software or Virtual Appliance (VMware, Xen or OracleVM) installation and follow the instructions in the appropriate Getting Started guide. We have created dedicated installation and configuration guides for each type of environment, as part of the documentation set for Pulse Virtual Traffic Manager - choose the right environment, and install the software and you are ready to go.   (You can find the complete set of user documentation here)   3. Discover Pulse vADC These Pulse community pages include a wide range of resources to help you explore Pulse vADC solutions. From setting up simple services, through to remote management with REST and SOAP, and high-performance data-plane control using TrafficScript, Pulse gives you a comprehensive set of tools to differentiate and prioritise applications and services. See below for some good starting points!   4. Scale up Pulse vADC Ready to scale up your performance? When you are ready to move to the next level, you can request a 30-day evaluation license to test the full power of Pulse Virtual Traffic Manager. You will be sent a license key by email, which you can upload into the Developer Edition - then you can run complete performance and load testing in your own data center or cloud platforms. This evaluation license key will include Pulse Virtual Traffic Manager, again with add-on options for web application firewall (WAF) and web content optimization (WCO).     5. More to explore on the Pulse Community Load-balancing using Pulse Virtual Traffic Manager Back to Basics - What is a Traffic Manager , Anyway? Introduction to the Pulse vADC Architecture Global Load Balancing with Pulse vADC Examples of Pulse vADC in action And more ...    
View full article
Looking for Installation and User Guides for Brocade vADC? User documentation is no longer included in the software download package with Brocade vTM, so the documentation can now be found on the  Brocade.com web pages .  
View full article
Installing Pulse vADC We have created dedicated installation and configuration guides for each type of deployment option, as part of the complete documentation set for Pulse Virtual Traffic Manager (Pulse vTM). There are a number of different deployment options, depending on whether you want to install vTM as a virtual appliance, in a cloud, on a bare-metal hardware appliance, or on a private server using a software installation. Choose the target platform here, and follow the link to the designated "Getting Started" guide:   Installing as a Virtual Appliance? Looking to run a trial on Microsoft Hyper-V, VMware, Xen, QVM/KEMU, or Oracle VM? Look here.   Installing in a Cloud? For information on installing in Google Cloud Platform, Amazon EC2, or Microsoft Azure, look here.   Installing on a Bare-Metal Hardware Appliance? To deploy the Pulse vTM appliance image on an approved server hardware platform, look here. For hardware compatibility information, see the Pulse vTM Hardware Compatibility List.   Installing as Pure Software? If you are installing onto a private server, or inside a VM running Linux or Solaris, look here.   Note that these links are valid for the Pulse vTM 17.4 software release. The most recent set of user documentation can always be found on https://www.pulsesecure.net/techpubs/ under the "Pulse vADC Solutions" section. This includes detailed configuration, REST API and TrafficScript programming guides.   (Copies of the "Getting Started" guides are attached to this article)  
View full article
We live in a virtualized world. Virtualization has fundamentally changed the way that we build, deploy, manage and maintain applications. Servers used to be static, time consuming to provision, expensive to maintain and often over provisioned and under utilize. Virtualization tipped  
View full article
We have made it easier to see which features are offered in which model of Brocade Virtual Traffic Manager: there are two feature groups, which are common to both fixed-sized licenses using the Brocade vTM, and in the capacity-based licensing scheme using the Brocade Services Director.  
View full article
by Aidan Clarke   Traffic IP (TIP) Groups are the key to how Brocade vADC delivers intelligent clustering, as we saw in the previous article. This is because we handle Traffic IP Addresses in a novel way - Traffic IP (TIP) Groups allow you to define one or more IP addresses to be used for an application endpoint, and you can decide how you want these IP addresses distributed across your cluster.   This means that you are not restricted to a single IP address allocated to a Virtual Server. Once your virtual server is configured, you simply bind it to one or more Traffic IP Groups, which gives you much greater flexibility in how you design your service.     A Traffic IP (TIP) Group is a “Listener” for incoming traffic to be “Load Balanced” TIP Groups can have one or more Traffic IP addresses TIP Groups can live on one or multiple Traffic Managers By default, TIP Groups are “Round Robin” distributed across the cluster   Service Example: With Brocade vADC: Application #1 must be Active/Active/Active on three nodes of a three-node cluster, but you want a warm standby node? Create a TIP Group with three IP addresses on a four-node vTM cluster with one of the nodes marked as passive (T1 above) Application #2 needs a simple Active/Standby configuration with a single IP address? Create a simple TIP group with one of the nodes as passive (T2 above) Application #3 must be Active/Active/Standby on a three-node cluster? Create a TIP Group with two IP addresses on a three-node cluster and (optionally) mark one of the cluster nodes as passive (T3 above) Application #4 must be active on all nodes of an eight node cluster but only have one IP address? Use a multicast enabled environment and deploy a multi-hosted Traffic IP Group. vADC will ensure the workload is evenly distributed across the cluster All of the above, at the same time for different Virtual Servers on the same cluster? No problem. Brocade vADC excels at all aspects of clustering     What happens when a node fails?   Brocade vADC monitors the health on all nodes, and when a node fails, then each service is reconfigured gracefully. In this example, if the second node fails, then:   Application #1 transfers workload to standby (node #4) Application #2 transfers workload to standby (node #3) Application #3 continues unchanged, but shares workload on node #4     During failover, session mapping is maintained for all nodes that remain active; and as standby nodes are brought online, session persistence can pin new user sessions to the new nodes. For recovery, or for planned maintenance, a node can be “drained” - no new sessions are pinned to the node - allowing for graceful reconfiguration or shutdown.   Traffic IP Groups allow for flexible allocation of workload as applications are brought online or reconfigured across a cluster, allowing you to express the relative priorities of applications in a shared infrastructure, an the desired behavior for failover and recovery.   And by increasing the number of cluster nodes dynamically, the scope of a node failure is reduced. By reducing the size of fault domains, services can recover more quickly, and additional nodes can be brought online to return services to full resilience.       This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Intelligent N+M Clustering Next: To be continued...    
View full article
by Aidan Clarke   In a previous article, we looked at how Brocade vADC is designed to be clustered in virtual and cloud environments. Unlike traditional HA architectures, you don't need cluster members to be Layer 2 adjacent, and nor are you restricted to simple Active/Standby configurations. In fact, there are THREE types of clustering which you might look for:   Clustering for Scale - Brocade vADC does not even limit you to two-way clustering - you can scale out to 64 nodes in a single cluster. And with each node able to drive over 140 Gbps in a single virtual instance, you have the choice to scale UP or scale OUT to suit any type of application architecture.   Clustering for Availability - Brocade vADC is not restricted to simple Active/Active and Active/Standby. You can build flexible N+M failover models, with shared or non-shared standby nodes, using Traffic IP Groups to define which services are hosted on which nodes, within a single cluster.   Clustering for Synchronization - In some architectures, you need to synchronize: each node needs to know the end points for every cluster member, so you have to replicate the configuration each time. With Brocade vADC, you define the cluster, and the configuration is replicated to all members - not just the end point IPs, but the business rules, traffic policies and access rights.     Brocade vADC excels at all three types of clustering, and there’s an extra bonus: all key capabilities such as web application security, content optimization, global load balancing and TrafficScript rules are supported and synchronized across all cluster members. Which lets you focus on what your application needs, rather than on restrictions imposed by networking and load balancing.   By contrast, traditional IT architectures meant that key capabilities were often not supported in clusters, so you might have to choose between performance, resilience and management - and lose critical capabilities.   The Brocade vADC portfolio is designed to cluster and scale horizontally - no matter what your workload, we can scale to meet it without compromising on the features offered. Configure your application once, and choose how you want the application spread across the cluster using Traffic IP Groups.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Active/Active Clustering for High Availability Next: Traffic IP Groups vs Virtual IP Addresses  
View full article
by Aidan Clarke   Traditional IT applications were simple: they lived in one place, in your data center. If you wanted more capacity, you added more servers, storage and networks. If you wanted to make the application more reliable, you doubled it to make it highly available: you had one system running “active” - while the other system waited on “standby.” This concept of “redundancy” was simple, so long as you could buy two of everything, and were happy that only half of the infrastructure was active at any one time - not an efficient solution.   But modern applications need a modern approach to performance, security and reliability: which is why Brocade vADC approaches things differently, a software solution for a software world, where distributed applications need an “always-active” architecture.   We often hear from IT professionals that they used to avoid Active/Active architectures; for fear that performance would be compromised under failure. Our customers routinely deploy Brocade vADC in Active/Active, or even Active/Active/Active/Active solutions all the time: they can choose the right balance between node and cluster size, to optimize the availability, while reducing the size of the fault domain.     Similarly, high-availability architectures used to require that HA peers were installed as Layer 2 adjacent (ie: on the same network). These architectures simply don't work in today's clouds; for example, AWS availability zones, by their very design, are on different Layer 3 networks. In order to run a Layer 2 HA pair in Amazon AWS, you need to put your whole solution in a single AWS Availability zone - a practice that Amazon architects strongly discourage.   With Brocade vADC, if you can connect to each other via a network, then you can cluster your application. Which means that you can choose an availability architecture to suit your application - whether it lives in your data center, in a cloud, or both.   Get started with Brocade vADC today, our Developer Edition is free to download and try out in your test and development environment.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: One ADC Platform, Any Environment Next: Intelligent N+M Clustering   
View full article
by Aidan Clarke   The Brocade vADC suite is designed to be flexible, extensible and portable software. Regardless of whether your applications run in the enterprise data center, in a private cloud, a public cloud or anything in between, Brocade's vADC can get you there.   Our solution was purpose-built for software deployment, and fits naturally into any virtual or cloud environment: and it was the first full functioning ADC solution available on VMWare, and has been in public clouds since the beginning - originally named Zeus ZXTM, it was launched on Amazon EC2 in 2009. The Brocade vADC platform only needs one simple thing to operate: a platform that can run Linux on an Intel platform. If you can do that, you can run Brocade vADC.     Brocade vADC offers native images for Amazon AWS, Microsoft Azure, Google Cloud Engine, Rackspace, Joyent, Sunguard and many more - and it is also available as a Virtual Appliance for VMware, HyperV, Xen Server, KVM and OracleVM.   Furthermore, Brocade Services Director can manage vADC workloads in all of these environments simultaneously: our customers can deploy Brocade Services Director in an enterprise Data Centre (DC) and use it to manage workloads in both the DC and the cloud at the same time.   Simply put, no matter where your applications run, Brocade vADC can be right there with them. And no matter where you go, it's the same vADC software ensuring your applications are Available, Scalable, Fast and Secure. Get started with Brocade vADC today, our Developer Edition is free to download and try out in your test and development environment.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Right-Size for Capacity Next: Active/Active Clustering for High Availability  
View full article
by Aidan Clarke and Paul Wallace   Today’s applications are built for innovation and customer experience, and it can be hard to predict how they will evolve if they hit a rapid growth curve. Which makes it very hard to plan ahead for capacity, especially when you don't know how your systems will scale under increased workloads.   Traditionally, IT organizations would need to plan far, far ahead. Not just for systems resources such as CPU, memory, storage and networks, but also for software licensing for larger-scale systems. This used to very complex, as software sizing often depended on workloads: you might need to translate your projected capacity (guess) into the numbers of CPUs required (guess) in order to calculate the number and type of software licensing required (another guess).   In order to hit the projected workloads, you might need more CPUs, for which you might need to buy bigger licenses. And just in case, you might round up to make sure that your application did not hit the CPU license limit at peak periods.     With Brocade vADC, we have taken some of the guesswork out of capacity planning. We don't limit the number of CPUs you can run on an instance. If you need more horsepower, simply add more CPUs to the workload and you can scale up to meet demand, up to the licensed capacity you have selected.   With a pure software architecture, Brocade vADC can monitor throughput and capacity, while optimizing the available CPU and memory. So if you provision a vADC with 1 Gbps ADC capacity, then it will only be limited by the available CPU/memory/networking. You can add complex business rules, deep security scanning, compression and SSL/TLS security, and you will still be able to deliver 1 Gbps throughput so long as the system has enough resources.   So while traditional IT architectures meant that you had to over-size your systems - sometimes you had to install 10 Gbps of capacity just to run a 1 Gbps workload - with Brocade vADC, you just need to provision enough CPU and memory to right-size your workload.   Get started with Brocade vADC today, our Developer Edition is free to download and try out in your test and development environment.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Agile Licensing for Agile Applications Next: One ADC Platform, Any Environment   
View full article
As someone once said, “Software is eating the world.” And now, everything we do ‘online’ or ‘digitally’ is delivered to us by applications.   As a result, developers are under pressure to deliver new applications, to enhance our online experience. And it falls to IT departments to install, enable, and protect those and  
View full article
Fixed-size licensing works for fixed-sized applications. If your application rarely changes, and sees a steady workload, then you can optimize the costs of the platform to match the resources you need.  
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Microsoft Exchange 2016.  
View full article