OBProxy uses the blacklist mechanism for self-adaptive access control for off-peak major compaction, upgrade, leader change, downtime, startup, and shutdown.
OBProxy supports two types of blacklists: down blacklist and live-but-unavailable blacklist. You can manage blacklists by setting the corresponding parameters.
You can use a blacklist to implement access control in the following scenarios:
Ensure that a zone involved in an off-peak major compaction cannot be accessed.
Ensure that an OBServer or zone in the cluster that is undergoing an upgrade cannot be accessed.
Ensure that a failed OBServer cannot be accessed.
Ensure that, after a partition migration, requests cannot be sent to the original OBServer of the partition.
Ensure that, when an OBServer to be accessed does not have tenant resources, OBProxy retries accessing other OBServers.
Ensure that, when an OBServer becomes live but unavailable (for example, the memory usage exceeds the specified threshold, the timeout value is reached, the OBServer is initialized, or the OBServer exits), OBProxy retries accessing other OBServers.
Down blacklist
If an OBServer is detected to be down or has suspended service provision after you execute the stop server command, the OBSever enters the down blacklist. Applications do not access OBServers on the blacklist. When this server is detected to be normal again, it is removed from the blacklist.
An OBServer enters the down blacklist in one of the following cases:
The value of the
start_service_timeparameter is 0.The value of the
statusparameter is inactive.
Live-but-unavailable blacklist
The status of an OBServer in a live-but-unavailable blacklist is temporary or uncertain. This differentiates it from a down blacklist. The system retries accessing it periodically. It is removed from the blacklist after it is found to be normal again.
An OBServer node enters the live-but-unavailable blacklist in one of the following cases:
The zone in which the OBServer is located is upgrading.
The server on which OBServer is deployed is upgrading.
The OBServer has reached the specified resource limit, connection limit, or memory limit, or the OBServer is being initialized or is exiting. An error is returned in these cases.
A server response times out or client connection times out.
Blacklist parameters
Log on to the sys tenant as the root user from a client.
Then, execute the following command to view the configuration parameters of OBProxy:
obclient> SHOW PROXYCONFIG;
To modify a parameter, use the
ALTER proxyconfig SET key=valuestatement. The modification takes effect immediately.The following table describes the parameters related to blacklisting.
Parameter Description enable_congestion Specifies whether the blacklist mechanism is enabled. The blacklist mechanism is enabled by default. When the blacklist mechanism malfunctions, you can temporarily disable it by modifying this parameter, so that OBProxy can work properly. congestion_failure_threshold Specifies the number of failures within N seconds after which an OBServer is blacklisted. If the value of this parameter is less than 0, all the OBServers are removed from the blacklist . congestion_fail_window The interval at which the number of errors resets to zero. Unit: second. The default value of this parameter is 120 seconds. If, within this cycle, the number of errors exceeds the value specified by congestion_failure_threshold, the OBServer is added to the blacklist. You can modify the value of this parameter in real time. After you modify this parameter, the current error count is reset to zero in the new fail window. congestion_retry_interval The time interval at which OBProxy retries to access a live-but-unavailable OBServer in the blacklist. Default value: 20 seconds. min_keep_congestion_interval The period after which an OBServer is removed from the blacklist. min_congested_connect_timeout The period after which a client connection times out. When a connection times out, the OBServer enters the live-but-unavailable blacklist. Default value: 100 ms.