-
Notifications
You must be signed in to change notification settings - Fork 1
virtualserver
Virtual servers are managed via the virtualserver route and package. Requests made to this route are asynchronous, with the exception of Fetch. Some clusters have over 1000 virtual services, so it's always best practice to include the limit=10 argument in your URL query. For CREATE, UPDATE, and DELETE, be sure to check the status of the record, using the FETCH+ID option.
The virtualserver route is the primary receiver for client requests. Before clients can start making requests, the loadbalancers data table must have at least one load balancer. See loadbalancer.
- Request is received by the API
- IP address is assigned to the VIP if one is not provided (if Infoblox integration is enabled)
- Load balancer (LB) is assigned to the VIP if one is not provided
- API checks database to see if VIP already exists
- API creates a database record for the resource
- API creates a status record for the resource
- API returns 200 to the client with initial staging data and Creating status
- API create HOST records for VIP (if Infoblox integration is enabled)
- LB manufacturer used to set SDK target
- API connects to the target load balancer and checks to see if VIP exists
- API builds out VIP's dependencies and ultimately creates the VIP
- API fetches VIP from load balancer
- API writes VIP data to database
- Request is received by the API
- API checks to see if record exists using ID field
- API creates a status record for the resource
- API returns 200 to the client with initial staging data and Updating status
- API checks to see if the record exists on the load balancer using the SourceUUID field.
- API updates record and dependencies
- API fetches VIP from load balancer
- API writes VIP data to database
- Request is received by the API
- API checks to see if record exists using ID field
- API creates a status record for the resource
- API returns 200 to the client with initial staging data and Deleting status
- API checks to see if the record exists on the load balancer using the SourceUUID field.
- API deletes record and dependencies
- API deletes VIP data from database
This is the parent struct where the virtual server Data configuration lives. This struct is defined in the common package.
| Go Field | Json | Data Type | Values | Description |
|---|---|---|---|---|
| Platform | platform | string | avi networks, netscaler | Used for automatic load balancer assignment and the WebUI. |
| LoadBalancerIP | load_balancer_ip | string | IP address of the AVI Controller Cluster or Netscaler management SNIP. Please note, this needs to be a SNIP that is shared across the HA pair. This field value MUST match a cluster_ip value in the loadbalancers database table. |
|
| ID | id | string | Database ID of the record (Update Only) |
The following struct stores the configuration for the virtual service resource.
| Go Field | Json | Data Type | Values | Description | Platforms |
|---|---|---|---|---|---|
| Name | name | string | Friendly name for this resource. | ALL | |
| ServiceType | service_type | string | http, https, https-no-secure-cookies, http-multiplex-disabled, ssl-l4-app, l4-app, l4-app-udp and ssl-bridge | Service associated with the VIP. Service types are defined under the loadbalancer package and part of the ServiceTypes collection. | ALL |
| IP | ip | string | IP Address of the VIP. | ALL | |
| Ports | ports | []Port | List of Port configurations. | ALL | |
| DNS | dns | []string | List of DNS names associated with the VIP. | ALL | |
| Enabled | enabled | bool | Enabled state of the VIP | ALL | |
| Certificates | certificates | []certificate.Data | List of Certificate configurations. Note that even though this is a list, most platforms only support one certificate. | AVI | |
| LoadBalancingMethod | load_balancing_method | string | roundrobin or leastconnection | How the VIP load balances traffic. | ALL |
| Pools | pools | []pool.Data | List of pool configurations. In the special case of AVI, more than one pool will result in a poolgroup with pool members. In the case of Netscaler, it will create either multiple services or service groups. | ALL | |
| ProductCode | _pool_group_uuid | int | Security Group identifier. RBAC component. | ALL | |
| SourcePoolGroupUUID | _pool_group_uuid | string | UUID of AVI pool group. This is unique per cluster. | AVI | |
| SourceStatus | _status | string | Status of the resource. Used to track ASYNC calls to the resource. | ALL | |
| SourceApplicationPolicy | _application_policy | string | UUID of AVI application policy. This is unique per cluster. | AVI | |
| SourceNetworkSecurityPolicyRef | _network_security_policy_ref | string | UUID of NetworkSecurityPolicyRef | AVI | |
| SourceUUID | _uuid | string | UUID of the resource. For AVI, it's an actual UUID and Netscaler will use the Name of the resource. | ALL | |
| SourceVrfRef | _vrf_ref | string | UUID of the VRF Context where the VIP lives. This is unique per cluster. | AVI | |
| SourceNsrBackupVip | _nsr_backup_vip | string | Name of the Netscaler backup vip associated with the VIP. | Netscaler | |
| SourceLast30 | _last_30 | string | Ticketmaster specific field that queries Prometheus to determine uptime over last 30 days. | Netscaler |
Fields starting with "Source" or "_" are immutable fields. They are required when updating records, and cannot be changed.
| ld | Json | Data Type | Values | Description | Platforms |
|---|---|---|---|---|---|
| Port | port | int | 1-65535 | Service port | ALL |
| L4Profile | l4_profile | string | tcp, udp, udp-fast-path-vdi, udp-per-pkt, etc. | Sets the L4 protocol. The supported profiles are defined in the loadbalancer package and part of the NetworkProfiles collection. | ALL |
| SSLEnabled | ssl_enabled | bool | Enables SSL on the port. | AVI |
Retrieves records. Supported arguments include:
- limit, number of records to return
- offset, if limit is 5, and total records is 10, then the offset would be 6 for the following page
- /record_id, returns only the record queried
GET https://<MY_API_INSTANCE>/api/v1/virtualserver #returns ALL records
GET https://<MY_API_INSTANCE>/api/v1/virtualserver?limit=10 #returns 10 records
GET https://<MY_API_INSTANCE>/api/v1/virtualserver?limit=10&offset=11 #returns the next 10 records, starting on 11
GET https://<MY_API_INSTANCE>/api/v1/virtualserver/333300e0b65d77cd8cb9beb634bfac9b #returns only record 333300e0b65d77cd8cb9beb634bfac9b
Record IDs are dynamically generated when the service is created. It is a hash of the load balancer, IP, and ports associated with the VIP. As long as these parameters are not changed, the system will always generate the same ID for the resource.
POST https://<MY_API_INSTANCE>/api/v1/virtualserver
{
"platform": "avi networks",
"load_balancer_ip": "10.10.1.150",
"data": {
"dns": [
"foobar.domain.local"
],
"enabled": true,
"load_balancing_method": "roundrobin",
"pools": [
{
"bindings": [
{
"enabled": true,
"server": {
"ip": "192.168.10.200"
}
}
],
"certificate": {},
"enabled": true,
"health_monitors": [
{
"receive_timeout": 15,
"response_codes": [],
"send_interval": 30,
"successful_count": 1,
"type": "tcp",
"monitor_port": 80
}
],
"name": "(New)",
"ssl_enabled": false,
"default_port": 80,
"persistence": {
"type": "client-ip"
}
}
],
"ports": [
{
"port": 80,
"l4_profile": "tcp"
}
],
"service_type": "http",
"name": "foo",
"product_code": 1234,
"ip": "192.168.10.100"
}
}
PUT https://<MY_API_INSTANCE>/api/v1/virtualserver
{
"data":{
"_application_policy":"System-HTTP",
"_last_30":0,
"_uuid":"virtualservice-a1c313ab-ab72-426d-9de9-495dffcea9bc",
"_vrf_ref":"vrfcontext-28adeb57-a368-4a80-9ad5-26bd0c40f673",
"dns":[
"foobar.domain.local"
],
"enabled":true,
"ip":"192.168.10.100",
"load_balancing_method":"roundrobin",
"name":"prd1234-foo-cjb",
"pools":[
{
"_load_balancing_method":"roundrobin",
"_uuid":"pool-b6fd888d-46df-4f54-8e06-e7354018253e",
"_vrf_ref":"vrfcontext-28adeb57-a368-4a80-9ad5-26bd0c40f673",
"bindings":[
{
"enabled":true,
"graceful_disable":false,
"port":0,
"server":{
"ip":"10.74.110.200"
}
}
],
"certificate":{
"key":{
}
},
"default_port":80,
"enabled":true,
"graceful_disable":false,
"health_monitors":[
{
"_uuid":"healthmonitor-0ab51ed1-3d1e-45cc-b8b0-7cd8e778fc8f",
"failed_count":2,
"name":"prd1234-foo-cjb-jo-tcp-oki",
"receive_timeout":15,
"send_interval":30,
"successful_count":1,
"type":"tcp"
}
],
"is_nsr_service":false,
"name":"prd1234-foo-cjb-jo",
"persistence":{
"_uuid":"applicationpersistenceprofile-cf4c9844-1b60-4c5b-a202-90c6ec1126e8",
"name":"prd1234-foo-cjb-jo-client-ip-zt",
"type":"client-ip"
},
"ssl_enabled":false
}
],
"ports":[
{
"l4_profile":"tcp",
"port":80,
"ssl_enabled":false
}
],
"product_code":1544,
"service_type":"http"
},
"id":"333300e0b65d77cd8cb9beb634bfac9b",
"last_modified":"2020-09-18T17:40:05.462797Z",
"_load_balancer":{
"mfr":"avi networks",
},
"load_balancer_ip":"10.10.1.150",
"last_modified_by":"cvillanueva",
"_sql_message":{
},
"_source_status":"deployed"
}WARNING omitting any fields or structs containing data may result in the removal of that setting. There currently isn't a PATCH method, so the entire configuration file must be submitted. For instance, if you have three bindings, and you submit a payload with two, it will remove the missing binding from the configuration!
Delete requires that the DELETE HTTP Method be sent to the virtualserver route and that the resource id is included.
DELETE https://<MY_API_INSTANCE>/api/v1/virtualserver/333300e0b65d77cd8cb9beb634bfac9b
The /api/v1/source/virtualserver route is used to collect all virtual server definitions. This operation is both concurrent and parallelized with a fixed semaphore of 64. This semaphore can be reduced if the parallelized requests are overloading the API.
- POST
/api/v1/source/virtualserverwill execute aggregation process - API will query the load balancer table and return the cluster_ip and manufacturer of each load balancer and compile a target list.
- API will loop through the target list, run the common.FetchAll() method from within a Go routine, and throttle the Go routines based on the semaphore value.
- Each Go routine will collect all the virtual server data from the load balancer and write a LBRecordCollection struct into a channel
- As the API receives each channel, it will add it to a LBRecordCollection list
- Once all channels are collected, the API will write the collections to the database
The aggregation process will parse the name of the VIPs to isolate the product code. By default, if a status record does not exist, the status of the aggregated record will be set to Deployed.