Кіріспе
Жоғары қолжетімділік кластерлері (сонымен қатар HA кластерлері, failover кластерлері деп те аталады) – ең аз тоқтау уақытымен сенімді пайдалануға болатын серверлік қосымшаларды қолдайтын компьютерлер тобы. Олар жүйелік компоненттердің істен шығуы кезінде үздіксіз қызмет көрсету үшін артық компьютерлерді топтарда немесе кластерлерде пайдалану үшін жоғары қолжетімділік бағдарламалық жасақтамасын қолданады. Егер кластерлеу болмаса, белгілі бір қосымшаны іске қосатын сервер құлап жатса, құлаған сервер жөнделгенше қосымша қолжетімсіз болады. HA кластерлеуі бұл мәселені аппараттық/бағдарламалық ақауларды анықтап, әкімшілік араласуды қажет етпей-ақ, басқа жүйеде қосымшаны дереу қайта іске қосу арқылы шешеді. Бұл процеске ауыстыру (failover) дейді. Бұл процестің бір бөлігі ретінде кластерлеу бағдарламалық жасақтамасы қосымшаны іске қосу алдында түйіннің конфигурациясын өзгертуі мүмкін. Мысалы, тиісті файлдық жүйелерді импорттап орнату, желілік жабдықты конфигурациялау және кейбір қосымша қосымшаларды іске қосу қажет болуы мүмкін. HA кластерлері көбінесе маңызды деректер базалары, желіде файлдарды бөлісу, бизнес-қосымшалар және электрондық коммерция веб-сайттары сияқты клиенттерге қызмет көрсету үшін қолданылады. HA кластерлерін жүзеге асыру кластерде жекелей сәтсіздік нүктелерін жою үшін, соның ішінде бірнеше желілік қосылымдар мен деректерді сақтау арқылы артық байланыспен деректерді сақтауға тырысады. HA кластерлері әдетте кластердегі әрбір түйіннің денсаулығы мен жағдайын бақылау үшін қолданылатын жеке желілік байланыс арқылы «жүрек соғуы» механизмін пайдаланады. Барлық кластерлік бағдарламалық жасақтамалардың шешуі тиіс маңызды мәселе – «мидың бөлінуі», ол барлық жеке байланыстар бір уақытта тоқтағанда, бірақ кластерлік түйіндер әлі де жұмыс істеп тұрғанда пайда болады. Мұндай жағдайда кластердегі әрбір түйін басқа түйіндердің бәрі құлап кеткенін дұрыс емес деп шешіп, басқа түйіндер әлі де іске қосылып жатқан қызметтерді іске қосуға тырысуы мүмкін. Қызметтердің дубликатталуы ортақ сақтаудағы деректердің бұзылуына әкелуі мүмкін. HA кластерлері мұндай жағдайды болдырмау үшін көбінесе кворум куәгерлік сақтауын (жергілікті немесе бұлтты) пайдаланады. Куәгерлік құрылғысы екіге бөлінген кластердің екі жағында да ортақ бола алмайды, сондықтан кластердің барлық мүшелері бір-бірімен байланыса алмаса (мысалы, «жүрек соғуы» бұзылғанда), мүше куәгерлікке қол жеткізе алмаса, ол белсенді бола алмайды.
High availability clusters (also known as HA clusters, fail over clusters) are groups of computers that support server applications that can be reliably utilized with a minimum amount of down time. They operate by using high availability software to harness redundant computers in groups or clusters that provide continued service when system components fail. Without clustering, if a server running a particular application crashes, the application will be unavailable until the crashed server is fixed. HA clustering remedies this situation by detecting hardware/software faults, and immediately restarting the application on another system without requiring administrative intervention, a process known as failover. As part of this process, clustering software may configure the node before starting the application on it. For example, appropriate file systems may need to be imported and mounted, network hardware may have to be configured, and some supporting applications may need to be running as well. HA clusters are often used for critical databases, file sharing on a network, business applications, and customer services such as electronic commerce websites. HA cluster implementations attempt to build redundancy into a cluster to eliminate single points of failure, including multiple network connections and data storage which is redundantly connected via storage area networks. HA clusters usually use a heartbeat private network connection which is used to monitor the health and status of each node in the cluster. One subtle but serious condition all clustering software must be able to handle is split brain, which occurs when all of the private links go down simultaneously, but the cluster nodes are still running. If that happens, each node in the cluster may mistakenly decide that every other node has gone down and attempt to start services that other nodes are still running. Having duplicate instances of services may cause data corruption on the shared storage. HA clusters often also use quorum witness storage (local or cloud) to avoid this scenario. A witness device cannot be shared between two halves of a split cluster, so in the event that all cluster members cannot communicate with each other (e. g., failed heartbeat), if a member cannot access the witness, it cannot become active.
Қолданбаның жобалау талаптары
Барлық қолданбалар жоғары қол жетімділік кластерлік ортада жұмыс істей алмайды, ал қажетті жобалау шешімдері бағдарламалық жасақтама жобалау кезеңінің басында қабылдануы керек. Жоғары қол жетімділік кластерлік ортада жұмыс істеу үшін қолданба кем дегенде келесі техникалық талаптарға сәйкес келуі керек, олардың соңғы екеуі кластерде сенімді жұмыс істеу үшін өте маңызды және толыққанды орындау қиын: Қолданбаны іске қосу, тоқтату, мәжбүрлеп тоқтату және оның күйін тексерудің салыстырмалы түрде оңай жолы болуы керек. Іс жүзінде, бұл қолданбаның бірнеше даналарын қолдауды қамтитын, қолданбаны басқару үшін командалық қатар интерфейсі немесе скрипттері болуы керек дегенді білдіреді. Қолданба ортақ сақтауды (NAS/SAN) пайдалана білуі тиіс. Ең маңыздысы, қолданба өзінің күйін мүмкіндігінше көп сақтайтын, уақытқа төзімді ортақ сақтау құрылғысында сақтауы керек. Сонымен қатар, ортақ сақтаудан сақталған күйді пайдаланып, сәтсіздікке ұшырағанға дейін соңғы күйде басқа түйінде қайта іске қосу мүмкіндігі де маңызды. Қолданба құлауы немесе сақталған күйден қайта іске қосылғанда деректердің бұзылуына жол бермеуі керек. Бұл шектеулердің бірқатары виртуалды серверлік ортаны пайдалану арқылы азайтылуы мүмкін, онда гипервизордың өзі кластерді біледі және физикалық хосттар арасында виртуалды машиналарды (оның ішінде жұмыс жад күйін) үздіксіз көшіруді қамтамасыз етеді. Бұл тәсіл мен кластерлік қолданбаларды іске қосу арасындағы басты айырмашылық – соңғысы серверлік қолданбалардың құлауын шеше алады және клиентке қызмет көрсетуге (мысалы, деректер базасына) қол жеткізуді сақтай отырып, бағдарламалық жасақтаманы тікелей «қозғалыс ортасында» жаңартуды қолдай алады, себебі бір дана қызмет көрсетіп тұрғанда екіншісі жаңартылып немесе жөнделіп жатыр. Бұл кластерлік даналардың байланыс орнатуын, кэштерді тазалауын және қол жеткізуді үйлестіруді қажет етеді. Ақаулықтарды жою кластерлеуді жоспарлауға, құруға, конфигурациялауға және түзетуге жатады.
There must be a relatively easy way to start, stop, force stop, and check the status of the application. In practical terms, this means the application must have a command line interface or scripts to control the application, including support for multiple instances of the application. The application must be able to use shared storage (NAS/SAN). Most importantly, the application must store as much of its state on non volatile shared storage as possible. Equally important is the ability to restart on another node at the last state before failure using the saved state from the shared storage. The application must not corrupt data if it crashes, or restarts from the saved state. A number of these constraints can be minimized through the use of virtual server environments, wherein the hypervisor itself is cluster aware and provides seamless migration of virtual machines (including running memory state) between physical hosts—see Microsoft Server 2012 and 2016 Failover Clusters. A key difference between this approach and running cluster aware applications is that the latter can deal with server application crashes and support live "rolling" software upgrades while maintaining client access to the service (e. g. database), by having one instance provide service while another is being upgraded or repaired. This requires the cluster instances to communicate, flush caches and coordinate file access during hand off. Failover clustering falls under planning, creating and configuring also troubleshooting.
Тораптың сенімділігі
HA кластерлері жеке жүйелерді және ортақ инфрақұрылымды мүмкіндігінше сенімді ету үшін барлық қолжетімді техникаларды пайдаланады. Оларға мыналар жатады:
Дискілерді көшіру (немесе тәуелсіз дискілердің артық массивтері – RAID), сондықтан ішкі дискілердің істен шығуы жүйелік құлауға әкелмейді. Distributed Replicated Block Device (ДРББ) – бір мысал. Желілік кабель, коммутатор немесе желілік интерфейс бұзылған жағдайда желінің тоқтауына жол бермес үшін артық желілік қосылымдар. Сақтау жүйесіне қосылудың үзілуіне (бұл ортақ ештеңе архитектурасын бұзушылыққа әкелер еді) алып келмейтіндей, артық сақтау аймағы желісі (SAN) қосылымдары, бір кабель, коммутатор немесе интерфейс бұзылған жағдайда. Әдетте, екі немесе барлық қуат көзі үзіліссіз қуат беру құрылғыларымен (UPS) қорғалған әртүрлі тізбектердегі артық электр қуаты кірістері және артық қуат көздері, сондықтан бір қуат беру желісі, кабель, UPS немесе қуат көзінің ақауы жүйеде қуаттың жоғалуына әкелмейді. Бұл мүмкіндіктер кластерлік ауысудың қажеттілігін азайтуға көмектеседі. Мұндай ауысу кезінде қызмет кем дегенде біраз уақытқа қолжетімсіз болады, сондықтан ауысуды болдырмау шаралары басымдыққа ие.
Disk mirroring (or Redundant Arrays of Independent Disks—RAID) so that failure of internal disks does not result in system crashes. The Distributed Replicated Block Device is one example. Redundant network connections so that single cable, switch, or network interface failures do not result in network outages. Redundant storage area network (SAN) connections so that single cable, switch, or interface failures do not lead to loss of connectivity to the storage (this would violate shared nothing architecture). Redundant electrical power inputs on different circuits, usually both or all protected by uninterruptible power supply units, and redundant power supply units, so that single power feed, cable, UPS, or power supply failures do not lead to loss of power to the system. These features help minimize the chances that the clustering failover between systems will be required. In such a failover, the service provided is unavailable for at least a little while, so measures to avoid failover are preferred.
Қалпына келтіру стратегиясы
Таратылған есептеудегі қателерді басқаратын жүйелерде қателерді жоюдың әртүрлі стратегиялары бар. Мысалы, Apache Cassandra API Hector қателіктерді жоюды конфигурациялаудың үш тәсілін анықтайды: "FAIL FAST" деп жазылатын Fail Fast, егер бірінші түйінге қол жеткізе алмаса, қателікті жою әрекеті сәтсіз аяқталады. "ON FAIL TRY ONE NEXT AVAILABLE" деп жазылатын On Fail, Try One Next Available, жүйе бір хостты, ең қолжетімдісін немесе қолда бар болса, оны сынап көреді. "ON FAIL TRY ALL AVAILABLE" деп жазылатын On Fail, Try All, жүйе барлық қолда бар түйіндерді сынап көреді.
Fail Fast, scripted as "FAIL FAST", means that the attempt to cure the failure fails if the first node cannot be reached. On Fail, Try One Next Available, scripted as "ON FAIL TRY ONE NEXT AVAILABLE", means that the system tries one host, the most accessible or available, before giving up. On Fail, Try All, scripted as "ON FAIL TRY ALL AVAILABLE", means that the system tries all existing, available nodes before giving up.