Jump to content
Welcome to our new Citrix community!
  • Multiple ways for a NetScaler to make AWS API calls


    Subhojit Goswami
    • Validation Status: Validated
      Summary: Multiple ways for a NetScaler to make AWS API calls
      Has Video?: No

     

     

    Multiple ways for a NetScaler to make AWS API calls

     

    Some example scenarios where a NetScaler needs to make API calls are as follows:

    • HA (High Availability): A high availability (HA) deployment of two NetScaler appliances can provide uninterrupted operation in any transaction. With one appliance configured as the primary node and the other as the secondary node, the primary node accepts connections and manages servers while the secondary node monitors the primary. If for any reason, the primary node is unable to accept connections, the secondary node takes over. Precisely for monitoring purposes, API calls have to be made from the secondary node to the primary and vice-versa.
     
    • Autoscale: Efficient hosting of applications in a cloud involves easy and cost-effective management of resources depending on the application demand. To meet increasing demand, one needs to scale network resources upward. Whether demand subsides, one needs to scale down to avoid the unnecessary cost of idle resources, and for this very reason, NetScaler VPX supports the AWS Auto Scaling service. Integrated with the AWS Auto Scaling service, the NetScaler VPX instances provide various advantages like Load Balance Management, High Availability, etc., and for these purposes, API calls have to be made.
    And many more example scenarios are there.

     

    This article will be showcasing three major ways for a NetScaler to make AWS API calls:

     

    1. Via the Internet Gateway:
    converted-file.thumb.png.9810484ce77c2644252055d3acfa55cf.png
        • Create a VPC.
        • Create an Internet Gateway and attach it to the VPC.
        • Create three subnets in the VPC within the same availability zone which should be of the following types:
                • Public Subnet for the client-facing VIP (virtual IP).
                • Public Subnet for the management of NetScaler (NSIP: NetScaler IP).
                • Private Subnet for the application servers (SNIP: Subnet IP).
        • Configure the common route table applicable to all the subnets.
                • The routing path for all the incoming and outgoing traffic via the internet gateway (the target should be the Internet Gateway ID).
                • The routing path for all the local communication between the subnets within the VPC.
        • Create and configure the security group for the NetScaler instance.
        • Create a NetScaler VPX instance from the Amazon Marketplace in the management public subnet. (While creating, select the existing security group and add the security group created just above this step).
        • Create two Network Interface which are of the following types:
                • One for the client subnet.
                • Another one is for the server subnet.
        • Attach the Network Interfaces created in the above step to the NetScaler instance that was just created.
        • Create two Elastic IPs and associate them to the client public subnet Network Interface and management public subnet Network Interface (this was generated automatically the moment the NetScaler instance was created in the management public subnet) respectively.
    For more details, please visit this link: https://docs.citrix.com/en-us/citrix-adc/current-release/deploying-vpx/deploy-aws/launch-vpx-for-aws-ami.html

    After the above setup is done, make sure that appropriate IAM roles and policies are associated with the NetScaler instance for the specific feature.

    For manual checking as to whether the NetScaler can make an API call, follow the steps below.

    Step 1:

    SSH into the NetScaler instance

    converted-file.thumb.png.d86256aaa9e81b317af62c44ac25c022.png

    Step 2:

    Run the following commands to verify if the NetScaler can make an API call:

    shell

    Python

    import boto3

    c = boto3.client(“ec2”, region_name = “xyz”) {Replace xyz with the appropriate region}

    c.describe_instances()

    converted-file.thumb.png.279a43a9ceb983a8d888f4bf9031b9a8.png

     

    1. Via the NAT (Network Address Translation) Gateway:
    converted-file.png.c6c5fb239d36b3133d430ffd4177316e.png

     

    The above setup is quite similar to that of the setup done for the API calling via the Internet Gateway, except for three major changes which are as follows:

        • In this setup, the management subnet and the client subnet of the NetScaler are also private. Hence, making the NetScaler instance completely private.
        • Since the NetScaler instance is completely private, so, to SSH into it, one must SSH into another EC2 instance which is public-facing but residing in the same VPC in a public subnet, and then use the shell of that public-facing EC2 instance to SSH into the NetScaler instance. For this to happen proper inbound rules have to be specified for the security group applied to the NetScaler instance, like only the incoming SSH request from the private IP of the public-facing EC2 instance will be allowed. The name of such a public-facing EC2 instance is called a Bastion Server.
        • Since the NetScaler instance is completely private, so, to make API calls over the internet, its requests must go through a NAT Gateway and an appropriate routing path must also be specified in the custom route table which should have the following routes:
                • The routing path for all the outgoing traffic via the NAT gateway (the target should be the NAT Gateway ID).
                • The routing path for all the local communication between the subnets within the VPC.

    After the above setup is done, make sure that appropriate IAM roles and policies are associated with the NetScaler instance.

    Now for NetScaler to make API calls via the internet gateway, the following steps must be followed:

    Step 1:

    SSH into the Bastion Server:

    Step 2:

    Create the key pair in the Bastion Server

    Step 3:

    SSH into the NetScaler instance from the Bastion Server:

    Repeat steps 1 and 2 from the Internet Gateway use case.

     

     

    1. Via the VPC Endpoint:
    converted-file.thumb.png.d9253906e485b5bee846babdfc55a0d2.png

     

    This setup is similar to that of the NAT Gateway setup with two minor changes, which are as follows:

    • Instead of the NAT Gateway in the public subnet, create a VPC Endpoint in the private management subnet.
    • Specify the appropriate routes in the custom route table of the private management subnet, which are as follows:
                • The routing path for all the outgoing traffic via the VPC Endpoint Network Interface (the target should be the VPC Endpoint Network Interface ID).
                • The routing path for all the local communication between the subnets within the VPC.
    The remaining steps to make the NetScaler carry out API calls are identical to that of the NAT Gateway use case.

    References

    For more debugging and understanding purposes, please visit the following links:

      

     

     


    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...