tencent cloud

Tencent Cloud Smart Advisor

Release Notes
Product Introduction
Overview
Features
Product Strengths
Scenarios
Customer Cases
Purchase Guide
Getting Started
Using TSA to Perform a Cloud Risk Assessment
Using TSA to Execute a Chaos Experiment on CFG
Operation Guide
Operation Guide to TSA-Cloud Architecture
Operation Guide to TSA-Cloud Risk Assessment
Operation Guide to TSA-Chaotic Fault Generator
Operation Guide to TSA-Digital Assets
Permission Management
API Documentation
History
Introduction
API Category
Making API Requests
Other APIs
Task APIs
Cloud Architecture Console APIs
Data Types
Error Codes
FAQs
FAQs: TSA
FAQs: TSA-Cloud Risk Assessment
FAQs: TSA-Cloud Architecture
FAQs: TSA-Chaotic Fault Generator
Related Protocol
Tencent Cloud Smart Advisor Service Level Agreement
PRIVACY POLICY MODULE CHAOTIC FAULT GENERATOR
DATA PRIVACY AND SECURITY AGREEMENT MODULE CHAOTIC FAULT GENERATOR
Contact Us

CLB Stop Fault

PDF
포커스 모드
폰트 크기
마지막 업데이트 시간: 2025-03-24 15:23:01

Background

As a proxy, Cloud Load Balancer (CLB) generally serves various business services by providing a cost-effective and transparent method to expand network device and server bandwidth, increase throughput, enhance network data processing capabilities, and improve network flexibility and availability.
As a crucial component of network transmission, CFG provides you the ability to simulate CLB stop faults, assisting you in achieving instance or listener unavailability.

Fault Principle

Injecting a stop fault into CLB causes instances or listeners to stop, and leads to client access failures.

Experiment Execution

Experiment Preparation

Create a virtual private cloud and deploy a CVM and CLB instance within this network. Deploy test services on the CVM instance and create listeners on the CLB instance to monitor the CVM service ports.

Experiment Steps

Step 1: Create an experiment

1. Log in to Tencent Cloud Smart Advisor > Chaotic Fault Generator, and enter the Experiment Management page, click Create a New Experiment.
2. Click Skip and create a blank experiment, and fill in the experiment details.
3. Add actions. The platform provides CLB Stop Fault Action.
Three stop objects are provided: CLB instance, Layer 4 path listener, and Layer 7 path listener.

Step 2: Execute experiment actions

Click Execute to distribute the fault actions. Log in to the same VPC instance and analyze the business service responses.

Observe Results

Stop Object: CLB Instance

1. In a steady-state metric performance, the corresponding instance status in the CLB console will show as Normal.
2. In a steady-state metric performance, the corresponding service responds normally when accessed via curl.

3. After fault injection, the corresponding instance status in the CLB console will show as stopped.
4. After fault injection, the service does not respond via curl.


Stop Object: Layer 4 Path Listener

In a steady-state metric performance, the listener service matched by the rule responds normally via curl.

After fault injection, the listener service matched by the rule does not respond via curl.


Stop Object: Layer 7 Path Listener

In a steady-state metric performance, the listener service matched by the rule responds normally via curl.

After fault injection, the listener service matched by the rule does not respond via curl.


Long Link Results Observation (SSH Simulated Long Link)

In a steady-state metric performance, the client can access normal and input command operations.

In a steady-state metric performance, long links with the client can be observed via netstat -tu on the server side.

After the fault injection, the original client can no longer be accessed, and command input is not possible.

After the fault injection, establishing a new long link does not respond.

After the fault injection, the server-side long link still exists.



도움말 및 지원

문제 해결에 도움이 되었나요?

피드백