ວິທີການສ້າງ autoscaler ຂອງທ່ານເອງສໍາລັບກຸ່ມ

ສະບາຍດີ! ພວກເຮົາຝຶກອົບຮົມຄົນໃຫ້ເຮັດວຽກກັບຂໍ້ມູນໃຫຍ່. ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຈິນຕະນາການໂຄງການການສຶກສາກ່ຽວກັບຂໍ້ມູນໃຫຍ່ໂດຍບໍ່ມີກຸ່ມຂອງຕົນເອງ, ເຊິ່ງຜູ້ເຂົ້າຮ່ວມທັງຫມົດເຮັດວຽກຮ່ວມກັນ. ສໍາລັບເຫດຜົນນີ້, ໂປຼແກຼມຂອງພວກເຮົາສະເຫມີມີມັນ :) ພວກເຮົາມີສ່ວນຮ່ວມໃນການຕັ້ງຄ່າ, ການປັບແຕ່ງແລະການບໍລິຫານຂອງມັນ, ແລະຜູ້ຊາຍໂດຍກົງເປີດຕົວວຽກ MapReduce ຢູ່ທີ່ນັ້ນແລະໃຊ້ Spark.

ໃນບົດຂຽນນີ້, ພວກເຮົາຈະບອກທ່ານວ່າພວກເຮົາແກ້ໄຂບັນຫາການໂຫຼດຂອງກຸ່ມທີ່ບໍ່ສະ ເໝີ ພາບໂດຍການຂຽນຕົວຂະ ໜາດ ອັດຕະໂນມັດຂອງພວກເຮົາເອງໂດຍໃຊ້ cloud. Mail.ru Cloud Solutions.

ບັນຫາ

ກຸ່ມຂອງພວກເຮົາບໍ່ໄດ້ໃຊ້ໃນຮູບແບບປົກກະຕິ. ການຖິ້ມຂີ້ເຫຍື້ອແມ່ນມີຄວາມບໍ່ສະເຫມີພາບສູງ. ຕົວຢ່າງ, ມີຫ້ອງຮຽນພາກປະຕິບັດ, ເມື່ອທັງຫມົດ 30 ຄົນແລະຄູສອນໄປຫາກຸ່ມແລະເລີ່ມໃຊ້ມັນ. ຫຼືອີກເທື່ອຫນຶ່ງ, ມີມື້ກ່ອນເສັ້ນຕາຍໃນເວລາທີ່ການໂຫຼດເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ສ່ວນທີ່ເຫຼືອຂອງເວລາທີ່ກຸ່ມເຮັດວຽກຢູ່ໃນໂຫມດ underload.

ການ​ແກ້​ໄຂ #1 ແມ່ນ​ການ​ຮັກ​ສາ​ກຸ່ມ​ທີ່​ຈະ​ທົນ​ທານ​ຕໍ່​ການ​ໂຫຼດ​ສູງ​ສຸດ​, ແຕ່​ຈະ​ບໍ່​ໄດ້​ເຮັດ​ວຽກ​ໃນ​ເວ​ລາ​ທີ່​ເຫຼືອ​.

ການ​ແກ້​ໄຂ #2 ແມ່ນ​ການ​ຮັກ​ສາ​ກຸ່ມ​ຂະ​ຫນາດ​ນ້ອຍ​, ທີ່​ທ່ານ​ຈະ​ເພີ່ມ​ຂໍ້​ຂອງ​ຕົນ​ກ່ອນ​ຫ້ອງ​ຮຽນ​ແລະ​ໃນ​ລະ​ຫວ່າງ​ການ​ໂຫຼດ​ສູງ​ສຸດ​.

ການແກ້ໄຂ #3 ແມ່ນເພື່ອຮັກສາກຸ່ມຂະຫນາດນ້ອຍແລະຂຽນ autoscaler ທີ່ຈະຕິດຕາມການໂຫຼດປະຈຸບັນຂອງ cluster ແລະ, ການນໍາໃຊ້ APIs ຕ່າງໆ, ເພີ່ມແລະເອົາ nodes ອອກຈາກ cluster.

ໃນບົດຂຽນນີ້, ພວກເຮົາຈະເວົ້າກ່ຽວກັບການແກ້ໄຂ #3. autoscaler ນີ້ແມ່ນຂຶ້ນກັບປັດໃຈພາຍນອກຫຼາຍກ່ວາພາຍໃນ, ແລະຜູ້ໃຫ້ບໍລິການມັກຈະບໍ່ສະຫນອງມັນ. ພວກເຮົາໃຊ້ໂຄງສ້າງຄລາວຂອງ Mail.ru Cloud Solutions ແລະຂຽນຕົວຂະຫຍາຍອັດຕະໂນມັດໂດຍໃຊ້ MCS API. ແລະນັບຕັ້ງແຕ່ພວກເຮົາສອນວິທີການເຮັດວຽກກັບຂໍ້ມູນ, ພວກເຮົາໄດ້ຕັດສິນໃຈທີ່ຈະສະແດງວິທີທີ່ທ່ານສາມາດຂຽນ autoscaler ທີ່ຄ້າຍຄືກັນສໍາລັບຈຸດປະສົງຂອງທ່ານເອງແລະນໍາໃຊ້ມັນກັບຄລາວຂອງທ່ານ.

ກໍາຫນົດເບື້ອງຕົ້ນ

ກ່ອນອື່ນ ໝົດ, ທ່ານຕ້ອງມີກຸ່ມ Hadoop. ຕົວຢ່າງ, ພວກເຮົາໃຊ້ການແຈກຢາຍ HDP.

ເພື່ອໃຫ້ nodes ຂອງທ່ານຖືກເພີ່ມແລະເອົາອອກຢ່າງໄວວາ, ທ່ານຕ້ອງມີການແຜ່ກະຈາຍທີ່ແນ່ນອນຂອງພາລະບົດບາດລະຫວ່າງ nodes.

1. ແມ່ບົດ node. ດີ, ບໍ່ມີຫຍັງພິເສດທີ່ຈະອະທິບາຍຢູ່ທີ່ນີ້: ໂຫນດຕົ້ນຕໍຂອງກຸ່ມ, ເຊິ່ງ, ສໍາລັບຕົວຢ່າງ, ໄດເວີ Spark ຖືກເປີດຕົວ, ຖ້າທ່ານໃຊ້ໂຫມດໂຕ້ຕອບ.
2. ໂຫນດວັນທີ. ນີ້​ແມ່ນ node ທີ່​ທ່ານ​ເກັບ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ HDFS ແລະ​ບ່ອນ​ທີ່​ການ​ຄິດ​ໄລ່​ເກີດ​ຂຶ້ນ​.
3. ໂນດຄອມພິວເຕີ. ນີ້ແມ່ນ node ບ່ອນທີ່ທ່ານບໍ່ເກັບຮັກສາຫຍັງຢູ່ໃນ HDFS, ແຕ່ບ່ອນທີ່ການຄິດໄລ່ເກີດຂຶ້ນ.

ຈຸດສໍາຄັນ. Autoscaling ຈະເກີດຂຶ້ນເນື່ອງຈາກ nodes ຂອງປະເພດທີສາມ. ຖ້າທ່ານເລີ່ມກິນແລະເພີ່ມຂໍ້ຂອງປະເພດທີສອງ, ຄວາມໄວການຕອບສະຫນອງຈະຕໍ່າຫຼາຍ - decommissioning and recommitting will take hours on your cluster . ນີ້, ແນ່ນອນ, ບໍ່ແມ່ນສິ່ງທີ່ທ່ານຄາດຫວັງຈາກ autoscaling. ນັ້ນແມ່ນ, ພວກເຮົາບໍ່ໄດ້ສໍາຜັດກັບຂໍ້ຂອງປະເພດທໍາອິດແລະທີສອງ. ພວກມັນຈະເປັນຕົວແທນຂອງກຸ່ມທີ່ມີຄວາມເປັນໄປໄດ້ຕໍ່າສຸດທີ່ຈະມີຢູ່ຕະຫຼອດໄລຍະເວລາຂອງໂຄງການ.

ດັ່ງນັ້ນ, autoscaler ຂອງພວກເຮົາຖືກຂຽນໄວ້ໃນ Python 3, ໃຊ້ Ambari API ເພື່ອຈັດການການບໍລິການກຸ່ມ, ໃຊ້ API ຈາກ Mail.ru Cloud Solutions (MCS) ສໍາລັບການເລີ່ມຕົ້ນແລະຢຸດເຄື່ອງ.

ສະຖາປັດຕະຍະກໍາການແກ້ໄຂ

1. ໂມດູນ autoscaler.py. ມັນປະກອບດ້ວຍສາມຊັ້ນຮຽນ: 1) ຫນ້າທີ່ເຮັດວຽກກັບ Ambari, 2) ຫນ້າທີ່ເຮັດວຽກກັບ MCS, 3) ຫນ້າທີ່ທີ່ກ່ຽວຂ້ອງໂດຍກົງກັບເຫດຜົນຂອງ autoscaler.
2. ສະຄຣິບ observer.py. ໂດຍພື້ນຖານແລ້ວມັນປະກອບດ້ວຍກົດລະບຽບທີ່ແຕກຕ່າງກັນ: ເວລາໃດແລະເວລາໃດທີ່ຈະໂທຫາຟັງຊັນ autoscaler.
3. ໄຟລ໌ການຕັ້ງຄ່າ config.py. ສໍາລັບຕົວຢ່າງ, ມັນມີບັນຊີລາຍຊື່ຂອງ nodes ອະນຸຍາດໃຫ້ສໍາລັບ autoscaling ແລະຕົວກໍານົດການອື່ນໆທີ່ມີຜົນກະທົບ, ຕົວຢ່າງ, ໄລຍະເວລາລໍຖ້າຈາກປັດຈຸບັນ node ໃຫມ່ໄດ້ຖືກເພີ່ມ. ນອກນັ້ນຍັງມີການສະແຕມເວລາສໍາລັບການເລີ່ມຕົ້ນຂອງຫ້ອງຮຽນ, ດັ່ງນັ້ນກ່ອນຫ້ອງຮຽນ, ການຕັ້ງຄ່າກຸ່ມທີ່ອະນຸຍາດສູງສຸດແມ່ນເປີດຕົວ.

ຕອນນີ້ໃຫ້ເບິ່ງຊິ້ນສ່ວນຂອງລະຫັດພາຍໃນສອງໄຟລ໌ທໍາອິດ.

1. ໂມດູນ Autoscaler.py

ຫ້ອງຮຽນ Ambari

ນີ້ແມ່ນສິ່ງທີ່ລະຫັດທີ່ມີຫ້ອງຮຽນມີລັກສະນະເປັນ Ambari:

class Ambari:
    def __init__(self, ambari_url, cluster_name, headers, auth):
        self.ambari_url = ambari_url
        self.cluster_name = cluster_name
        self.headers = headers
        self.auth = auth

    def stop_all_services(self, hostname):
        url = self.ambari_url + self.cluster_name + '/hosts/' + hostname + '/host_components/'
        url2 = self.ambari_url + self.cluster_name + '/hosts/' + hostname
        req0 = requests.get(url2, headers=self.headers, auth=self.auth)
        services = req0.json()['host_components']
        services_list = list(map(lambda x: x['HostRoles']['component_name'], services))
        data = {
            "RequestInfo": {
                "context":"Stop All Host Components",
                "operation_level": {
                    "level":"HOST",
                    "cluster_name": self.cluster_name,
                    "host_names": hostname
                },
                "query":"HostRoles/component_name.in({0})".format(",".join(services_list))
            },
            "Body": {
                "HostRoles": {
                    "state":"INSTALLED"
                }
            }
        }
        req = requests.put(url, data=json.dumps(data), headers=self.headers, auth=self.auth)
        if req.status_code in [200, 201, 202]:
            message = 'Request accepted'
        else:
            message = req.status_code
        return message

ຂ້າງເທິງ, ເປັນຕົວຢ່າງ, ທ່ານສາມາດເບິ່ງການປະຕິບັດຫນ້າທີ່ stop_all_services, ເຊິ່ງຢຸດການບໍລິການທັງຫມົດໃນ node cluster ທີ່ຕ້ອງການ.

ຢູ່ທາງເຂົ້າຫ້ອງຮຽນ Ambari ເຈົ້າຜ່ານ:

• ambari_url, ສໍາລັບການຍົກຕົວຢ່າງ, ຄື 'http://localhost:8080/api/v1/clusters/',
• cluster_name - ຊື່​ຂອງ​ກຸ່ມ​ຂອງ​ທ່ານ​ໃນ Ambari​,
• headers = {'X-Requested-By': 'ambari'}
• ແລະພາຍໃນ auth ນີ້ແມ່ນຊື່ຜູ້ໃຊ້ ແລະລະຫັດຜ່ານຂອງທ່ານສໍາລັບ Ambari: auth = ('login', 'password').

ຟັງຊັນຕົວມັນເອງແມ່ນບໍ່ມີຫຍັງຫຼາຍກ່ວາສອງການໂທຜ່ານ REST API ກັບ Ambari. ຈາກທັດສະນະທີ່ສົມເຫດສົມຜົນ, ພວກເຮົາທໍາອິດໄດ້ຮັບບັນຊີລາຍຊື່ຂອງການບໍລິການແລ່ນຢູ່ໃນ node, ແລະຫຼັງຈາກນັ້ນຖາມກ່ຽວກັບກຸ່ມທີ່ໃຫ້, ໃນ node ໃດຫນຶ່ງ, ເພື່ອໂອນການບໍລິການຈາກບັນຊີລາຍຊື່ໄປຫາລັດ. INSTALLED. ຟັງຊັນສໍາລັບການເປີດຕົວບໍລິການທັງຫມົດ, ສໍາລັບການໂອນ nodes ກັບລັດ Maintenance ແລະອື່ນໆເບິ່ງຄ້າຍຄືກັນ - ພວກເຂົາແມ່ນພຽງແຕ່ການຮ້ອງຂໍຈໍານວນຫນ້ອຍຜ່ານ API.

ຫ້ອງຮຽນ Mcs

ນີ້ແມ່ນສິ່ງທີ່ລະຫັດທີ່ມີຫ້ອງຮຽນມີລັກສະນະເປັນ Mcs:

class Mcs:
    def __init__(self, id1, id2, password):
        self.id1 = id1
        self.id2 = id2
        self.password = password
        self.mcs_host = 'https://infra.mail.ru:8774/v2.1'

    def vm_turn_on(self, hostname):
        self.token = self.get_mcs_token()
        host = self.hostname_to_vmname(hostname)
        vm_id = self.get_vm_id(host)
        mcs_url1 = self.mcs_host + '/servers/' + self.vm_id + '/action'
        headers = {
            'X-Auth-Token': '{0}'.format(self.token),
            'Content-Type': 'application/json'
        }
        data = {'os-start' : 'null'}
        mcs = requests.post(mcs_url1, data=json.dumps(data), headers=headers)
        return mcs.status_code

ຢູ່ທາງເຂົ້າຫ້ອງຮຽນ Mcs ພວກເຮົາຜ່ານ id ໂຄງການພາຍໃນຄລາວແລະ id ຜູ້ໃຊ້, ເຊັ່ນດຽວກັນກັບລະຫັດຜ່ານຂອງລາວ. ຢູ່ໃນຫນ້າທີ່ vm_turn_on ພວກເຮົາຕ້ອງການເປີດເຄື່ອງຫນຶ່ງ. ເຫດຜົນຢູ່ທີ່ນີ້ແມ່ນສັບສົນກວ່າເລັກນ້ອຍ. ໃນຕອນເລີ່ມຕົ້ນຂອງລະຫັດ, ສາມຫນ້າທີ່ອື່ນເອີ້ນວ່າ: 1) ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຮັບ token, 2) ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ປ່ຽນ hostname ເປັນຊື່ຂອງເຄື່ອງໃນ MCS, 3) ໄດ້ id ຂອງເຄື່ອງນີ້. ຕໍ່ໄປ, ພວກເຮົາພຽງແຕ່ເຮັດຄໍາຮ້ອງຂໍຕອບແລະເປີດຕົວເຄື່ອງນີ້.

ນີ້ແມ່ນສິ່ງທີ່ຫນ້າທີ່ສໍາລັບການໄດ້ຮັບ token ເບິ່ງຄືວ່າ:

def get_mcs_token(self):
        url = 'https://infra.mail.ru:35357/v3/auth/tokens?nocatalog'
        headers = {'Content-Type': 'application/json'}
        data = {
            'auth': {
                'identity': {
                    'methods': ['password'],
                    'password': {
                        'user': {
                            'id': self.id1,
                            'password': self.password
                        }
                    }
                },
                'scope': {
                    'project': {
                        'id': self.id2
                    }
                }
            }
        }
        params = (('nocatalog', ''),)
        req = requests.post(url, data=json.dumps(data), headers=headers, params=params)
        self.token = req.headers['X-Subject-Token']
        return self.token

ຫ້ອງຮຽນອັດຕະໂນມັດ

ຫ້ອງຮຽນນີ້ມີຟັງຊັນທີ່ກ່ຽວຂ້ອງກັບ logic ການດໍາເນີນງານຂອງມັນເອງ.

ນີ້ແມ່ນສິ່ງທີ່ລະຫັດຂອງຊັ້ນຮຽນນີ້ເບິ່ງຄືວ່າ:

class Autoscaler:
    def __init__(self, ambari, mcs, scaling_hosts, yarn_ram_per_node, yarn_cpu_per_node):
        self.scaling_hosts = scaling_hosts
        self.ambari = ambari
        self.mcs = mcs
        self.q_ram = deque()
        self.q_cpu = deque()
        self.num = 0
        self.yarn_ram_per_node = yarn_ram_per_node
        self.yarn_cpu_per_node = yarn_cpu_per_node

    def scale_down(self, hostname):
        flag1 = flag2 = flag3 = flag4 = flag5 = False
        if hostname in self.scaling_hosts:
            while True:
                time.sleep(5)
                status1 = self.ambari.decommission_nodemanager(hostname)
                if status1 == 'Request accepted' or status1 == 500:
                    flag1 = True
                    logging.info('Decomission request accepted: {0}'.format(flag1))
                    break
            while True:
                time.sleep(5)
                status3 = self.ambari.check_service(hostname, 'NODEMANAGER')
                if status3 == 'INSTALLED':
                    flag3 = True
                    logging.info('Nodemaneger decommissioned: {0}'.format(flag3))
                    break
            while True:
                time.sleep(5)
                status2 = self.ambari.maintenance_on(hostname)
                if status2 == 'Request accepted' or status2 == 500:
                    flag2 = True
                    logging.info('Maintenance request accepted: {0}'.format(flag2))
                    break
            while True:
                time.sleep(5)
                status4 = self.ambari.check_maintenance(hostname, 'NODEMANAGER')
                if status4 == 'ON' or status4 == 'IMPLIED_FROM_HOST':
                    flag4 = True
                    self.ambari.stop_all_services(hostname)
                    logging.info('Maintenance is on: {0}'.format(flag4))
                    logging.info('Stopping services')
                    break
            time.sleep(90)
            status5 = self.mcs.vm_turn_off(hostname)
            while True:
                time.sleep(5)
                status5 = self.mcs.get_vm_info(hostname)['server']['status']
                if status5 == 'SHUTOFF':
                    flag5 = True
                    logging.info('VM is turned off: {0}'.format(flag5))
                    break
            if flag1 and flag2 and flag3 and flag4 and flag5:
                message = 'Success'
                logging.info('Scale-down finished')
                logging.info('Cooldown period has started. Wait for several minutes')
        return message

ພວກເຮົາຍອມຮັບຫ້ອງຮຽນສໍາລັບການເຂົ້າ. Ambari и Mcs, ບັນຊີລາຍຊື່ຂອງ nodes ທີ່ໄດ້ຮັບອະນຸຍາດສໍາລັບການປັບຂະຫນາດ, ເຊັ່ນດຽວກັນກັບຕົວກໍານົດການຂອງ node: ຫນ່ວຍຄວາມຈໍາແລະ cpu ຈັດສັນໃຫ້ກັບ node ໃນ YARN. ນອກຈາກນີ້ຍັງມີ 2 ຕົວກໍານົດການພາຍໃນ q_ram, q_cpu, ເຊິ່ງເປັນແຖວ. ການນໍາໃຊ້ພວກມັນ, ພວກເຮົາເກັບຄ່າຂອງການໂຫຼດຂອງກຸ່ມປະຈຸບັນ. ຖ້າພວກເຮົາເຫັນວ່າໃນໄລຍະ 5 ນາທີທີ່ຜ່ານມາມີການໂຫຼດເພີ່ມຂຶ້ນຢ່າງຕໍ່ເນື່ອງ, ຫຼັງຈາກນັ້ນພວກເຮົາຕັດສິນໃຈວ່າພວກເຮົາຈໍາເປັນຕ້ອງເພີ່ມ +1 node ກັບກຸ່ມ. ອັນດຽວກັນແມ່ນເປັນຄວາມຈິງສໍາລັບສະຖານະຂອງ cluster underutilization.

ລະຫັດຂ້າງເທິງນີ້ແມ່ນຕົວຢ່າງຂອງຟັງຊັນທີ່ເອົາເຄື່ອງຈັກອອກຈາກ cluster ແລະຢຸດມັນຢູ່ໃນຄລາວ. ກ່ອນອື່ນ ໝົດ, ມີການຍົກເລີກ YARN Nodemanager, ຫຼັງຈາກນັ້ນໂຫມດເປີດ Maintenance, ຫຼັງຈາກນັ້ນພວກເຮົາຢຸດເຊົາການບໍລິການທັງຫມົດໃນເຄື່ອງແລະປິດເຄື່ອງ virtual ໃນຄລາວ.

2. script observer.py

ລະຫັດຕົວຢ່າງຈາກນັ້ນ:

if scaler.assert_up(config.scale_up_thresholds) == True:
        hostname = cloud.get_vm_to_up(config.scaling_hosts)
        if hostname != None:
            status1 = scaler.scale_up(hostname)
            if status1 == 'Success':
                text = {"text": "{0} has been successfully scaled-up".format(hostname)}
                post = {"text": "{0}".format(text)}
                json_data = json.dumps(post)
                req = requests.post(webhook, data=json_data.encode('ascii'), headers={'Content-Type': 'application/json'})
                time.sleep(config.cooldown_period*60)

ໃນມັນ, ພວກເຮົາກວດເບິ່ງວ່າເງື່ອນໄຂຕ່າງໆໄດ້ຖືກສ້າງຂື້ນສໍາລັບການເພີ່ມຄວາມອາດສາມາດຂອງກຸ່ມແລະວ່າມີເຄື່ອງຈັກໃດໆຢູ່ໃນສະຫງວນ, ເອົາຊື່ເຈົ້າພາບຂອງຫນຶ່ງໃນນັ້ນ, ເພີ່ມມັນໃສ່ກຸ່ມແລະເຜີຍແຜ່ຂໍ້ຄວາມກ່ຽວກັບມັນຢູ່ໃນ Slack ຂອງທີມງານຂອງພວກເຮົາ. ຫຼັງຈາກນັ້ນ, ມັນເລີ່ມຕົ້ນ cooldown_period, ເມື່ອພວກເຮົາບໍ່ເພີ່ມຫຼືເອົາສິ່ງໃດອອກຈາກກຸ່ມ, ແຕ່ພຽງແຕ່ຕິດຕາມການໂຫຼດ. ຖ້າມັນມີຄວາມຫມັ້ນຄົງແລະຢູ່ໃນແລວເສດຖະກິດຂອງມູນຄ່າການໂຫຼດທີ່ດີທີ່ສຸດ, ພວກເຮົາພຽງແຕ່ສືບຕໍ່ຕິດຕາມ. ຖ້າຫນຶ່ງ node ບໍ່ພຽງພໍ, ຫຼັງຈາກນັ້ນພວກເຮົາເພີ່ມອີກອັນຫນຶ່ງ.

ສໍາລັບກໍລະນີທີ່ພວກເຮົາມີບົດຮຽນລ່ວງຫນ້າ, ພວກເຮົາຮູ້ແລ້ວວ່າຫນຶ່ງ node ຈະບໍ່ພຽງພໍ, ດັ່ງນັ້ນພວກເຮົາທັນທີເລີ່ມຕົ້ນ nodes ຟຣີທັງຫມົດແລະຮັກສາໃຫ້ເຂົາເຈົ້າມີການເຄື່ອນໄຫວຈົນກ່ວາໃນຕອນທ້າຍຂອງບົດຮຽນໄດ້. ອັນນີ້ເກີດຂຶ້ນໂດຍໃຊ້ລາຍຊື່ເວລາຂອງກິດຈະກໍາ.

ສະຫລຸບ

Autoscaler ເປັນການແກ້ໄຂທີ່ດີແລະສະດວກສໍາລັບກໍລະນີເຫຼົ່ານັ້ນເມື່ອທ່ານປະສົບກັບການໂຫຼດຂອງກຸ່ມທີ່ບໍ່ສະເຫມີກັນ. ທ່ານພ້ອມໆກັນບັນລຸການຕັ້ງຄ່າກຸ່ມທີ່ຕ້ອງການສໍາລັບການໂຫຼດສູງສຸດແລະໃນເວລາດຽວກັນບໍ່ຮັກສາກຸ່ມນີ້ໃນລະຫວ່າງການໂຫຼດ, ປະຫຍັດເງິນ. ດີ, ບວກທັງຫມົດນີ້ເກີດຂຶ້ນໂດຍອັດຕະໂນມັດໂດຍບໍ່ມີການເຂົ້າຮ່ວມຂອງທ່ານ. autoscaler ຕົວຂອງມັນເອງແມ່ນບໍ່ມີຫຍັງນອກເຫນືອການກໍານົດການຮ້ອງຂໍໃຫ້ API ຜູ້ຈັດການກຸ່ມແລະ API ຜູ້ໃຫ້ບໍລິການຟັງ, ຂຽນຕາມເຫດຜົນທີ່ແນ່ນອນ. ສິ່ງທີ່ທ່ານ ຈຳ ເປັນຕ້ອງຈື່ຢ່າງແນ່ນອນແມ່ນການແບ່ງສ່ວນຂອງຂໍ້ອອກເປັນ 3 ປະເພດ, ດັ່ງທີ່ພວກເຮົາຂຽນກ່ອນ ໜ້າ ນີ້. ແລະເຈົ້າຈະມີຄວາມສຸກ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com