cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
Installing Brocade vADC   We have created dedicated installation and configuration guides for each type of deployment option, as part of the complete documentation set for Brocade Virtual Traffic Manager (Brocade 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 Brocade vTM appliance image on an approved server hardware platform, look here. For hardware compatibility information, see the Brocade 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 Brocade vTM 17.4 software release. The most recent set of user documentation can always be found on Brocade.com, in the Document Library on the Brocade vTM product page. 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 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
The Brocade Services Director makes it easy to manage a fleet of virtual ADC services, with each application supported by dedicated vADC instances, such as Brocade Virtual Traffic Manager (Brocade vTM). In fact, Services Director can even support mixed versions of Brocade vTM, which means that some applications can be managed with an older version of Brocade vTM, while others with the very latest version of Brocade vTM.   Generally speaking, compatibility with older, supported versions of Services Director will be maintained in each new vTM release. In other words, you should be able to upgrade vTM without losing Services Director functionality. Some Service Director features rely on changes introduced into vTM, and will only be available when Services Director is managing vTM versions that expose the feature in question.   This table summarises the compatibility between supported versions of Services Director and Virtual Traffic Manager:     Brocade Services Director   2.4 (LTS) 2.5 2.6 17.1 17.2 Brocade vTM           9.9 (LTS) 1 1 1 1 1 10.4 (LTS) Y 1 1 1 1 11.0 Y Y Y Y Y 11.1 Y Y Y Y Y 17.1 Y Y Y Y Y     Key to the Table   Y   This combination is fully compatible, supporting all capabilities which are supported in both of the corresponding versions of SD and vTM   1   This combination is compatible, but some features are NOT fully supported, depending on the respective versions of SD and vTM     Limitations of feature support: Although the table above indicates that most combinations are supported to some extent, some key capabilities are of course dependent on the respective versions of SD and of vTM. The capability must be available by both your installation of Services Director and the instance of vTM, in order to be fully functional.   For example, the capability for instances of vTM to “Self-Register” with Services Director is only supported in Services Director 2.4 and higher, and in vTM versions 10.4 and higher:   Example SD Capability Available from which version   Services Director vTM vTM Cluster Awareness 2.3 10.3 vTM Instance Health 2.4 10.2 vTM Self Registration 2.4 10.4 vTM Backup/Restore 2.5 11.0     This data is correct at the time of last update - April 2017.  For combinations of SD and vTM not shown in this table , please contact your Brocade technical sales representative.    
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
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
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
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Microsoft Exchange 2010.
View full article
I have zipped up some icons and Visio stencils that our technical teams use when they are creating diagrams. I have included different formats, including solid and sketch styles:   Attached three files: brocade-vadc-product-icons.zip - PNG files brocade-vadc-visio-stencils-1.zip - Visio files brocade-vadc-visio-stencils-2.zip - Visio files        
View full article
This article describes the installation, configuration, and usage of the vADC Package for VMWare vRealize Orchestrator (vRO).   The package contains a number of workflows which can communicate with both the Brocade VTM, and the Brocade Services Director via REST APIs. The workflows support licensing and registration of newly deployed vTMs, and also pushing configuration to the vTMs themselves (either directly or via the Services Director).
View full article
A new policy (baseline version 201606021442) for the Virtual Web Application Firewall is now available. Change log: Changed: XSS via IMG tag - Reason: simplify rule Changed: XSS via LAYER tag - Reason: simplify rule Changed: XSS via BASE tag - Reason: simplify rule The download in the product is available with a short delay.
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager in Skype for Business architectures.
View full article
Pulse Secure vADC solutions are supported on Google Cloud Platform, with hourly billing options for applications that need to scale on-demand to match varying workloads. A range of Pulse Secure Virtual Traffic Manager (Pulse vTM) editions are available, including options for the Pulse vTM Developer Edition and Pulse Secure Virtual Web Application Firewall (Pulse vWAF), available as both a virtual machine and as a software installation on a Linux virtual machine.   This article describes how to quickly  create  a new Pulse   vTM instance through the Google Cloud Launcher. For additional information about the use and configuration of your Pulse vTM instance, see the product documentation available at https://www.brocade.com/vadc-docs.   Launching a  Pulse   vTM Virtual Machine Instance   To launch a new instance of the  Pulse   vTM virtual machine, use the GCE Cloud Launcher Web site. Type the following URL into your Web browser:   https://cloud.google.com/launcher Browse or use the search tool to locate the Pulse Secure package applicable to your requirements, then click the package icon to see the   package detail screen.       To deploy a new   Pulse  vTM instance   1.  To start the process of deploying a new instance, click Launch on Compute Engine.   2.  Type an identifying name for the instance, select the image version, then select the desired geographic zone and machine type. Individual zones might have differing computing resources available and specific access restrictions. Contact your support provider for further details. 3.  Ensure the boot disk correspond to your computing resource requirements. Pulse Secure recommends not changing the default disk size as this might affect the performance of your Pulse vTM.   4.  By default, GCE creates firewall rules to allow HTTP and HTTPS traffic, and to allow access to the Web-based Pulse vTM Admin UI on TCP port 9090. To instead restrict access to these services, untick the corresponding firewall checkboxes.   Note: If you disable access to TCP port 9090, you cannot access the Pulse vTM Admin UI to configure the instance.   5.  If you want to use IP Forwarding with this instance, click More and set IP forwarding to "On".   6.  Pulse  vTM needs access to the Google Cloud Compute API, as indicated in the API Access section. Keep this option enabled to ensure your instance can function correctly.   7.  Click Deploy  to launch the Pulse vTM instance.   The Google Developer Console confirms that your Pulse vTM instance is being deployed.     Next Steps   After your new instance has been created, you can proceed to configure your Pulse vTM software through its Admin UI.   To access the Admin UI for a successfully deployed instance, click Log into the admin panel.       When you connect to the Admin UI for the first time, Pulse vTM presents the  Initial Configuration wizard . This wizard captures the networking, date/time, and basic system settings needed by your Pulse vTM software to operate normally.   For full details of the configuration process, and for instructions on performing various other administrative tasks, see the Cloud Services Installation and Getting Started Guide .
View full article
Introduction   This article discusses how to prepare a bootable USB flash drive for use with the Brocade vTM appliance image.   To read more about the process of setting up the appliance image on your prepared USB flash drive, see the Brocade Virtual Traffic Manager: Appliance Image Installation and Getting Started Guide.   Erasing a USB flash drive   Brocade recommends first using the usb-creator-gtk tool to perform a full erase/format of the USB drive you want to use. This tool is available on most standard Linux-based workstations and includes a graphical user interface.     To erase a USB flash drive with usb-creator-gtk   Insert a USB drive into your workstation. Select your USB drive in the "Disk to use" list. Click Erase Disk. Alternatively, use any tool or command-line program that is able to fully erase your USB drive.   After you have completed this process, follow the instructions to set up the Brocade vTM appliance image in  the Brocade Virtual Traffic Manager: Appliance Image Installation and Getting Started Guide .   Note: To deploy the Brocade vTM appliance image on a USB flash drive, your selected flash drive must be bootable. Check with your USB flash drive vendor to verify its suitability if it appears not to be detected when attempting to boot from it after following the procedure above.
View full article
Overview   The libQueue TrafficScript library allows you to create and manage HTTP sessions on the Traffic Manager, and limit the number of sessions which are allowed through to the backend. With this library we can set a max number of serviceable sessions, and then the vTM will ensure that no more than that number of sessions are allowed through to the backend servers.   The library allows you to name multiple queues if you have multiple applications running through the same vTM, and use counters to keep track of the number of sessions, being created, re-used, and destroyed on the system.   Whenever the max number of users is reached the vTM will start delivering holding pages, which can be configured to include the users position in the queue. Ajax or a meta-rfresh can be used to refresh the users position periodically to keep them appraise of their position.   Please read the comments in the libQueue library for more information on its configuration.   Usage   Once the library has been imported, you will need to call the init() function to initialise the defaults for use. You can then if you wish override any of the configuration parameters as required. The do_req() function is used to determine if the user can be sent through to the application or sent to the Waiting Room.    import libQueue as queue; $config=[]; $houseKeeping=[]; $counters=[]; queue.init($config, $houseKeeping, $counters); # ===================================================================== # == Configuration Overrides for this host $config["poolName"] = "MyApplicationPool"; $config["queueName"] = "MyQueue"; $config["waitingRoomTemplatePage"] = "myApplicationWaitingRoom.html"; $config["waitingRoomTooBusyPage"] = "toobusy.html"; # ===================================================================== $pool = queue.do_req($config,$houseKeeping,$counters); if ($pool == $config["poolName"] ) { pool.use("www.demo.local"); } else { pool.use("WaitingRoom"); }   The waitingRoomTemplatePage will be parsed for template variables whenever it is delivered to a user. This allows you to brand the page, and also include information about the users queue position in the response. The current template variables available for the waiting room page are:   QUEUE_ID (Displays the PID of the vtm Child process managing this user) SESSION_ID (Displays the Session ID of the current user) QUEUE_POSITION (The users current position in their queue) All occurences of the above text will be replaced with their values, when the page is sent to the user.   More Information   The vTM software is designed to scale vertically within in a machine, and so it creates a single threaded child process per core. This library tries to scale in the same manor and so each child process creates and manages its own queue.   Each child is responsible for managing its own queue. This includes putting new user sessions into the queue, and running house keeping task on that queue to expire timedout sessions. When a queue is not empty, the child which owns the queue is also responsible for migrating users out of the queue and into the application.   The library needs to be configured with the number of cores available to the vTM, so that each child process can deQueue a proportianate number of users whenever migration occurs.   Debugging There is a debug function in the library, which can be set to any number between 0 and 5. However it is recommended that debugging only be enabled during testing, and set to 0 for production use.   User Counters The User Counters in the configuration can be used to visualise sessions being created, re-used, timed-out, and destroyed, for both the Application Pool and the Queue (Waiting Room). The default counter assignments are:   Session New (a new session has been Created) Session Update (A users session has been extended)  Session Expire (The housekeeping process has removed an expired session) Application Sessions (A session is assigned to the application pool) WaitingRoomSessions (A session which is in the queue) WaitingRoomExpire (A user in the queue has timed out) WaitingRoomMigrated (A session has migrated from the queue to the application) SessionComplete (A user hit an exit point and the session was deleted)    Timeouts There a three configuration parameters for timeouts. InitialTimeout is given to all new sessions and is there to prevent automated clients from using up real sessions. Once a session has been reused, then we switch to the standard timeout, either the sessionTimeout or the WaitingRoomTimeout depending on where the user was assigned.   Application and WaitingRoom sizes The script needs to be given the max number of application sessions allowed in the sessionLimit config value. when this limit is reached users will be sent to the WaitingRoom (queue). There is also a waitingRoomLimit, which when exceeded will cause the user to simply be given WaitingRoomTooBusy page.  
View full article