Introduction to cluster concept (i)
Overview: write down the original intent and motivation of this document, derived from the Oracle Basic operating Manual of the previous article. The Oracle Basic Operations Manual is a summary of the author's vacation on Oracle's foundational knowledge learning. Then form a summary of the system, a review review, the other is easy to use. This document is also derived from this text. Before reading the Oracle RAC installation and use tutorial, I will first comb the whole idea and formation of this article. Due to the different levels of knowledge storage for readers, I will start with the preparation and planning of Oracle RAC before installing the deployment of Oracle RAC. Began with the guidance of Dr. Tang, the database cluster configuration installation, before and after 2, 3 months of groping. A lot of problems are encountered in the middle. This document will also be documented. This article original/finishing, reproduced please mark the original source: Introduction of cluster concept (i)
Bai NINGSU July 16, 2015
Cluster concept Introduction Cluster terminology notice
Service hardware: Refers to the hardware that provides computing services, such as PC, PC server.
Service entities: Service entities typically refer to service software and service hardware.
Node: An isolated host running the Heartbeat process is called a node, which is the core component of HA, running the operating system and Heartbeat software services on each node.
Resource (Resource): A resource is an entity that can be controlled by a node that can be taken over by other nodes in the event of a node failure. such as: Disk partitions, file systems, IP addresses, application services, shared storage
Event: An event is something that can happen in a cluster, such as a node system failure, network connectivity failure, NIC failure, and application failure. These events cause the node's resources to be transferred, and HA's tests are based on these events.
What is a cluster
A cluster (cluster) is a group of computers that, as a whole, provide users with a set of network resources, which are nodes of a cluster. The cluster provides the following key features.
(i) scalability. The performance of a cluster is not limited to a single service entity, and new service entities can be added dynamically to the cluster, thereby enhancing the performance of the cluster.
(ii) High availability. The cluster makes the client exempt from the "out of service" warning by redundancy of the service entity. When a node server fails, the application running on this server will be automatically taken over on the other node server. Eliminating single points of failure is important for enhanced data availability, accessibility, and reliability.
(c) Load balancing. Load balancing distributes tasks evenly to compute and network resources in a clustered environment to improve data throughput.
(d) Error recovery. If a server in the cluster cannot be used due to a failure or maintenance need, resources and applications will be transferred to the available cluster nodes. Because the resources in one node do not work, the process of another available node that can transparently take over and continue to complete the task is called error recovery.
The links and differences between distributed and clustered are as follows:
(a) distributed means the distribution of different businesses in different places.
(b) Clusters refer to the pooling of several servers to achieve the same business.
(c) Distributed each node, can do cluster, and cluster is not necessarily distributed. and distributed, from the narrow sense, but also similar to the cluster, but its organization is relatively loose, unlike clustering, there is a certain organizational, a server outage, the other servers can be top up. distributed to each node, the completion of a different business, a node outage, the business is inaccessible.
Clusters are divided into three main categories:
HA: Highly available cluster (high availability Cluster).
LBC: Load Balancing cluster/Load Balancing system (load Balance Cluster)
HPC: Cluster of scientific computing clusters (high performance Computing Cluster)/performance computing (higher performance Computing).
Why build a DB cluster
With the rapid development of the economy, the expansion of enterprise scale, the number of enterprise users, the explosive growth of data volume, the database put forward a severe test. For all databases, in addition to documenting the correct processing results, the following challenges are faced.
- How to improve the processing speed to achieve a balanced load of the database.
- How to ensure the availability of databases, data security, and how to achieve data cluster scalability.
- How to solve these problems comprehensively has become the focus of many enterprises.
In the database, the formation of clusters is the same reason, mainly for the following reasons:
(a) with the growth of enterprises, the increase in business volume, database access and data volume rapid growth, its processing capacity and computing speed also increased correspondingly, so that a single device simply can not bear.
(b) In the above circumstances, if you throw away the existing equipment, do a lot of hardware upgrades, will inevitably lead to the waste of existing resources, and the next time the volume of business to upgrade, but also facing the high investment of hardware upgrades. Therefore, people want to build a cluster through a few small and medium-sized servers to achieve the load balance and continuous expansion of the database, when the need for higher database processing speed, as long as the simple increase of the database server can be extended.
(c) The database as the core of information system, plays a very important role, a single device can not guarantee the continuous operation of the system, if the occurrence of system failure, will seriously affect the normal operation of the system, and even bring huge economic losses. Therefore, people want to build a database cluster, to achieve high availability of the database, when a node fails, the system will automatically detect and transfer the application of the fault node, to ensure the continuous work of the database.
(iv) The enterprise database holds important information of the enterprise, some core data even related to the lifeblood of the enterprise, a single device can not guarantee the security of the database, once lost, it is difficult to find back. Therefore, people want to build a database cluster, to achieve the redundancy of the data set, by backing up data to ensure security.
Classification of DB clusters
Database clustering technology is to combine multiple servers to form a cluster to achieve a comprehensive performance better than a single large server technology, this technology can not only meet the needs of the application, but also a substantial savings in investment costs. Database clustering technology belongs to two kinds of systems: Cluster technology based on database engine and cluster technology based on database Gateway (middleware). In the context of DB cluster products, these include Oracle RAC, Microsoft MSCS, IBM db2udb, Sybase ASE, and Icx-uds of cluster technology based on database Gateway (middleware), which mainly includes database engine-based clustering technology.
Generally speaking, the focus of the database cluster software and the problem to be solved are divided into three main categories:
- The load Balancing cluster (load Balance CLUSTER,LBC) focuses on the scale-out of the database and improves the performance of the database.
- The High availability cluster (HI availability CLUSTER,HAC) focuses on ensuring that database applications continue. Most of the database clusters focus on this.
- L High Security CLUSTER,HSC focuses on disaster recovery.
Only Oracle RAC can achieve the above three aspects
Scalable, distributed database architecture
(i) Oracle RAC:
The most important feature of the architecture is the shared storage architecture (Shared-storage), where the entire RAC cluster is built on a shared storage device, with high-speed network interconnection between nodes. Oraclerac provides very good high-availability features, such as load balancing and application transparent slicing (TAF), with the greatest advantage of being completely transparent to the application and switching to a RAC cluster without modification. But the scalability of RAC is limited, first because the entire cluster relies on the underlying shared storage, so the I/O capability and availability of the shared storage determines the capabilities that the entire cluster can provide , and for I/O intensive applications, such a mechanism determines that subsequent expansion can only be The scale up (scaling up) type is relatively high for hardware costs, developer requirements, and maintenance costs. Oracle is clearly aware of this problem, and in Oracle's MAA (Maximum availability Architecture) architecture, the ability to integrate multiple storage devices with ASM allows the shared storage devices at the bottom of the RAC to have linear scaling capabilities, The entire cluster no longer relies on the processing power and availability of large storage.
Another problem with RAC is that as the number of nodes increases, the cost of inter-node communication increases , and when a certain limit is reached, increasing the nodes may not result in performance improvements or even performance degradation. The main reason for this problem is that Oracle RAC is transparent to the application, and the application can connect to any node in the cluster, and the communication overhead between the RAC nodes can seriously affect the processing power of the cluster when the application contention resources on different nodes. So there are two recommendations for using the ORACLE RAC:
L Communication between nodes using high-speed internet;
L Distribute different applications to different nodes as much as possible.
For this reason, Oracle RAC is typically extensible in the DSS environment (DSS decision support system) because the DSS environment can easily distribute different tasks on different compute nodes, whereas for OLTP applications (on -line Transaction processing online transaction processing system), Oracle RAC is more used to increase availability than to increase scalability.
(ii) MySQL Cluster
The MySQL cluster is completely different from the Oracle RAC, which employs a shared nothing architecture. The entire cluster consists of a management node (NDB_MGMD), a processing node (mysqld) , and a storage node (ndbd), and there is no shared storage device. MySQL cluster is primarily implemented using the NDB storage engine, which is a memory-based storage engine that requires data to be fully loaded into memory. The data is automatically distributed across the different storage nodes in the cluster, and each storage node holds only one shard of the complete data (fragment). At the same time, users can set up the same data to be stored on multiple different storage nodes to ensure that a single point of failure does not result in data loss. MySQL cluster is composed mainly of 3 parts:
- L SQL server node
- L NDB Data Storage node
- L Monitor and manage nodes
Such hierarchies are also related to the architecture in which MySQL itself separates SQL processing and storage. The advantage of MySQL cluster is that it is a distributed database cluster, processing nodes and storage nodes can be linearly increased, the whole cluster has no single point of failure, the availability and scalability can be high, more suitable for OLTP applications. But the problem with it is:
- L NDB ("NDB" is an "in-memory" storage engine with high availability and good data consistency. The storage engine must require that all data be loaded into memory, the limit is large, but the new version of NDB has been improved to allow only the index data to be loaded in memory, and the data can be saved on disk.
- The current MySQL cluster performance is not ideal, because the data is distributed to different storage nodes according to the primary key hash, if the application is not through the primary key to obtain data, it must be scanned on all storage nodes, return the results to the processing node processing. Moreover, the write operation needs to write multiple copies of the data to different storage nodes, and the network requirement between nodes is very high.
Although MySQL cluster current performance is not ideal, but share nothing architecture must be the future trend, Oracle after taking over MySQL, also vigorously develop MySQL cluster, I have great expectations of the future of MySQL cluster.
(iii) Distributed database architecture
After MySQL 5, the Data table partitioning feature (sharding), sharding is not a feature attached to a particular database software, but an abstraction over specific technical details, is a solution for horizontal scaling (scale out, or scale-out, scaling out). Its main purpose is to overcome the I/O capability limit of single node database server and solve the problem of database extensibility. For example, Oracle's RAC is a shared storage mechanism, for I/O intensive applications, bottlenecks can easily fall on the storage, such a mechanism determines that the subsequent expansion is only the scale up (scaling up) type, for hardware costs, developer requirements, maintenance costs are relatively high. Sharding is basically an extensibility solution for open source databases, and few have heard of commercial databases being sharding. The current trend in the industry is basically to embrace scale out and gradually liberate it from scale up.
The advantage of the sharding architecture is that the cluster is scalable and can be scaled almost linearly, and the availability of the entire cluster is high, with some node failures that do not affect the service of other nodes. Sharding principle is simple, easy to implement, is a very good solution to the database extensibility. Sharding is not a silver bullet for database expansion scenarios, and it is not suitable for scenarios such as transactional applications that can cause complex application architectures or limit the functionality of the system, which is also a drawback.reading and writing separation is an important idea of architecture distributed system。 A lot of system overall processing capacity and can not keep pace with the growth of the business, so will inevitably bring bottlenecks, simple upgrade hardware can not be once and for all. For the characteristics of the business type, we need to make a series of adjustment from the architecture pattern, such as the division of Business module, the splitting of database and so on. Centralized and distributed are two opposing models, the application characteristics of the industry also determines the structure of the idea.such as the internet industry in some portal sites, for technical and cost reasons, more open-source database products such asmysqL), since most of the requests are typically read-write-less, they provide the conditions for MYSQL and its replication technology to be a great way to go. In contrast to some traditional, dense-trading industries,such as telecommunications, finance, etc., considering the single-point processing capability and reliability, stability and other issues, may be more use of commercial databases, such asDB2, Oraclesuch as On the database level, most of the traditional industry core library uses a centralized architecture idea, the use of high-provisioned minicomputer as host carrier, because the database itself and the host powerful processing capacity, the database can generally support the operation of the business, therefore, the Oracle read-write separation of the architecture relative to MySQL, relatively less. The read-Write separation architecture utilizes the replication technology of the database to distribute the reading and writing on different processing nodes, thus achieving the purpose of improving usability and extensibility. The most common practice is to take advantage of MySQL Replication technology, Master DB assumes write operations, replicates data changes to multiple Slave DB, and assumes read operations. This architecture is suitable for read-intensive types of applications, and the read performance can grow linearly by increasing the number of Slave DB. To avoid a single point of failure in Master DB, the cluster generally uses two master DB for dual-machine hot standby, so the read and write availability of the entire cluster is very high. In addition to MySQL,Oraclefrom 11gThe ability to start providing Active Standby is alsoThe Foundation for implementing a read-write separation architecture。 The flaw in the read-write separation architecture is that each node must hold the full data, whether it be Master or Slave, and if, in large amounts of data, the cluster's scalability is limited to the storage capacity of a single node, and for write-intensive types of applications, The read-write separation architecture is not appropriate.
Using Oracle read/write separation, writer DB and Reader db use log replication software for real-time synchronization; writer DB is responsible for transaction related real-time query and transaction processing, Reader DB is responsible for read-only access, processing some non-real-time transaction details, Report class summary query, etc. 。 At the same time, in order to meet the requirements of high availability and scalability, the read-write end of the appropriate extension, such as Writer DB using HA or RAC architecture mode, currently, in addition to the database vendor cluster products, the solution of database expansion capacity of the main methods are two: data fragmentation and read and write separation. The principle of data fragmentation (sharding) is to slice the data horizontally, similar to the principle of hash partitioning, and the application architecture to address access Routing and Reader DB can be used in multiple sets, through load balancing or business separation, to effectively share the pressure of reading library.
For the Shared-nothing database schema mode, one of the core problems is the real-time synchronization of the read-write library, and while reader DB is only responsible for business queries, it does not mean that the database is functionally read-only. Read-only is from an application perspective, in order to ensure data consistency and conflict considerations, because the query business module may need to involve some intermediate processing, if you need to process in the database (depending on the application requirements and design), so reader DB still needs to be writable. Let's talk about the problem of data synchronization technology selection:
There are many techniques for real-time data synchronization, based on the OS layer (for example, VERITAS VVR), storage-based replication (which is mostly supported in high-end storage), application-based distribution, or database-layer based technology. Because data synchronization may not be a single DB full-Library synchronization, it involves issues such as business data selection and multi-source consolidation, so OS replication and storage replication are often not the preferred technology for read-write separations. Log-based Oracle replication technology, Oracle's own components can be implemented, but also has mature commercial software. Choosing a commercial standalone product or Oracle's own component capabilities depends on a variety of factors. such as the team's corresponding technical operation and maintenance capacity, project input costs, business system load level.
With Oracle's own component capabilities, no Logical Standby, stream, and 11g physical Standby (Active Data Guard), the stream is the most flexible, but most unstable, 11g Physica L Standby supports recovery and read-only parallelism, but because it is not a logical application mechanism of logs, it is most limited in the scenario of read-write separation. Using Oracle's own components is entirely feasible if the technical team is sufficiently informed about the technology and the processing power of the selection scheme can support data synchronization requirements. Choose commercially available products, more for stability, processing power and more. There are a number of mature Oracle replication software on the market, whether it is a veteran shareplex, or the realsync of the local DSG company and the nine Bridge company DDS, or Oracle upstart Goldengate, is a choice of objectives. With the acquisition and promotion of GoldenGate by Oracle, individuals believe that GoldenGate will be a big hit in disaster tolerance, data distribution and synchronization. Of course, the architecture good one reliable distributed read-write separation system, but also need to do a lot of application design, not in the scope of this article.
(iv) CAP and BASE theory
Distributed Domain CAP theory:
- L Consistency (consistency), data consistent update, all data changes are synchronized
- L Availability (availability), good response performance
- L Partition tolerance (partition fault tolerance) reliability
Theorem: Any distributed system can only meet two points at the same time, not three of them.
Advice: Architects should not waste their energy on how to design a perfect distributed system that satisfies the three, but should make a choice.
The ACID model of a relational database has high consistency + availability and is difficult to partition:
- L atomicity atomicity: All operations in a transaction must be completed or not completed.
- L Consistency consistency. At the beginning or end of a transaction, the database should be in a consistent state.
- L Isolation isolation layer. The transaction assumes that only it is operating the database itself and is unaware of each other.
- L Durability. Once the transaction is complete, it cannot be returned.
(v) Cross-database transactions
2PC (two-phase commit), 2PC is the anti-scalability pattern (Pat helland), which means that traditional relational databases are very difficult to implement a distributed DB cluster, The ability to scale a relational database is limited. In recent years, the development and growth of the NoSQL (non-relational database) movement, through the sacrifice of strong consistency, using the BASE model, with the idea of final consistency to design a distributed system, so that the system can achieve high availability and scalability. So, is it possible to implement a set of distributed database clusters, both to ensure availability and consistency, but also to provide good scalability?
The main realization of BASE thought is to divide the database according to function sharding fragment base idea mainly emphasizes the basic usability, if you need high availability, that is, the pure performance, then must be consistent or fault tolerance as the sacrifice, the BASE idea of the scheme has the potential to dig in the performance.
- L In common: All is the alternative to relational database SQL, logic with the data distribution, any model can be persisted, the data processing and storage separation, read and write separation, storage can be asynchronous or synchronous, depending on the degree of consistency requirements.
- L Different points: Key-value storage products such as NOSQL are the product BOX that meets the relational database header, and can be used in non-Java areas such as PHP Ruby, which is a product that you can use, while domain model + distributed cache + Storage is a complex architectural solution, not a product , but this approach is more flexible and should be the architect's master.
At present, there are many distributed database products, but most of them are DSS-oriented applications, because compared to OLTP applications, DSS applications are more likely to do distributed expansion, such as the Greenplum based on PostgreSQL development, it is good to solve the problem of usability and extensibility, and provides a very powerful parallel computing capability. For OLTP applications, business characteristics determine their requirements: high availability, consistency, short response times, support transactions and joins, and more. Databases and NoSQL as more and more NoSQL products emerge, they have features that many relational databases do not have, and can do well in terms of usability and extensibility.
First, NoSQL scenarios are very limited, and a type of NoSQL is designed for specific types of scenarios only. Relational databases are much more versatile, and NoSQL has to figure out if their application is appropriate.
Second, the use of relational database with application architecture, such as sharding and read-write separation technology, can also build a highly available and scalable distributed database cluster.
Third, the relational database manufacturers are still very strong, the world has a large number of users, the demand will inevitably promote the advent of new products.
Finally, hardware is evolving, such as the maturing of flash technology, where flash memory can be used as a cache between disk and memory, or a complete replacement for disk. And the memory price is getting lower and bigger, the in-memory cache or database is more and more widely used, which can bring the order of magnitude performance improvement to the application. The IO problems faced by the database will be greatly improved.
Reference documents
- Oracle Cluster Concepts and principles: Oracle's three highly available cluster scenarios http://www.linuxidc.com/Linux/2011-11/46779.htm
- Introduction to cluster Concept: The Oracle Advanced Course--theoretical textbook
- Oracle one-off RAC Survival Guide: http://book.51cto.com/art/200806/77753.htm
- Build a highly available Oracle database system: Oracle 11GR2 RAC Management and performance optimization:: http://book.51cto.com/art/201208/353749.htm
Tail Note: This article original/finishing, reproduced please mark the original source: Introduction to cluster concept (i)
Introduction to the cluster concept of "Oracle Cluster" Oracle DATABASE 11G RAC Detailed tutorial (i.)