集羣技術案例介紹和具體操做

集羣技術案例介紹和具體操做

1.1 什麼是集羣
簡單的說，集羣（cluster）就是一組計算機，它們做爲一個總體向用戶提
供一組網絡資源。這些單個的計算機系統就是集羣的節點（node）。一個理想的
集羣是，用戶歷來不會意識到集羣系統底層的節點，在他/她們看來，集羣是一
個系統，而非多個計算機系統。而且集羣系統的管理員能夠隨意增長和刪改集羣
系統的節點。

1.2 爲何須要集羣
集羣並非一個全新的概念，其實早在七十年代計算機廠商和研究機構就
開始了對集羣系統的研究和開發。因爲主要用於科學工程計算，因此這些系統並
不爲你們所熟知。直到Linux集羣的出現，集羣的概念才得以廣爲傳播。
對集羣的研究起源於集羣系統良好的性能可擴展性(scalability)。提升CPU
主頻和總線帶寬是最初提供計算機性能的主要手段。可是這一手段對系統性能的
提供是有限的。接着人們經過增長CPU個數和內存容量來提升性能，因而出現了
向量機，對稱多處理機(SMP)等。可是當CPU的個數超過某一閾值，象SMP這些
多處理機系統的可擴展性就變的極差。主要瓶頸在於CPU訪問內存的帶寬並不能
隨着CPU個數的增長而有效增加。與SMP相反，集羣系統的性能隨着CPU個數的
增長几乎是線性變化的。圖1顯示了這中狀況。
圖1. 幾種計算機系統的可擴展性
對於關鍵業務，停機一般是災難性的。由於停機帶來的損失也是巨大的。下
面的統計數字列舉了不一樣類型企業應用系統停機所帶來的損失。
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
×××西安網絡中心 中科紅旗linux培訓認證中心
應用系統每分鐘損失(美圓)
呼叫中心(Call Center) 27000
企業資源計劃(ERP)系統13000
供應鏈管理(SCM)系統11000
電子商務(eCommerce)系統10000
客戶服務(Customer Service Center)系統27000
圖2：停機給企業帶來的損失
隨着企業愈來愈依賴於信息技術，因爲系統停機而帶來的損失也越拉越大。
集羣系統的優勢並不只在於此。下面列舉了集羣系統的主要優勢：
高可擴展性：如上所述。
高可用性：集羣中的一個節點失效，它的任務可傳遞給其餘節點。能夠有效防止單點失效。
高性能：負載平衡集羣容許系統同時接入更多的用戶。
高性價比：能夠採用廉價的符合工業標準的硬件構造高性能的系統。

2.1 集羣系統的分類
雖然，根據集羣系統的不一樣特徵能夠有多種分類方法，可是通常把集羣系統分爲兩類：
（1）、高可用(High Availability)集羣,簡稱HA集羣。
這類集羣致力於提供高度可靠的服務。就是利用集羣系統的容錯性對外提供7*24小時不間
斷的服務，如高可用的文件服務器、數據庫服務等關鍵應用。
目前已經有在Linux下的高可用集羣，如Linux HA項目。
負載均衡集羣：使任務能夠在集羣中儘量平均地分攤不一樣的計算機進行處理，充分利
用集羣的處理能力，提升對任務的處理效率。
在實際應用中這幾種集羣類型可能會混合使用，以提供更加高效穩定的服務。如在一個使
用的網絡流量負載均衡集羣中，就會包含高可用的網絡文件系統、高可用的網絡服務。
（2）、性能計算(High Perfermance Computing)集羣，簡稱HPC集羣，也稱爲科學計算
集羣。
在這種集羣上運行的是專門開發的並行應用程序，它能夠把一個問題的數據分佈到多
臺的計算機上，利用這些計算機的共同資源來完成計算任務，從而能夠解決單機不能勝任
的工做（如問題規模太大，單機計算速度太慢）。
這類集羣致力於提供單個計算機所不能提供的強大的計算能力。如天氣預報、石油勘探與油
藏模擬、分子模擬、生物計算等。這些應用一般在並行通信環境MPI、PVM等中開發，因爲MPI

比較有名的集羣Beowulf就是一種科學計算集羣項目。

三、集羣系統轉發方式和調度算法

3．1轉發方式
目前LVS主要有三種請求轉發方式和八種調度算法。根據請求轉發方式的不一樣，所構
架集羣的網絡拓撲、安裝方式、性能表現也各不相同。用LVS主要能夠架構三種形式的集羣，
分別是LVS/NAT、LVS/TUN和LVS/DR，能夠根據須要選擇其中一種。
（1）、網絡地址轉換（LVS/NAT）
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
×××西安網絡中心 中科紅旗linux培訓認證中心
（2）、直接路由
（3）、IP隧道

三種轉發方式的比較：
3．二、調度算法
在選定轉發方式的狀況下，採用哪一種調度算法將決定整個負載均衡的性能表現，不一樣
的算法適用於不一樣的應用場合，有時可能須要針對特殊場合，自行設計調度算法。LVS的算
法是逐漸豐富起來的，最初LVS只提供4種調度算法，後來發展到如下八種：
1.輪叫調度（Round Robin）
調度器經過「輪叫」調度算法將外部請求按順序輪流分配到集羣中的真實服務器上，它均
等地對待每一臺服務器，而無論服務器上實際的鏈接數和系統負載。
2.加權輪叫（Weighted Round Robin）
調度器經過「加權輪叫」調度算法根據真實服務器的不一樣處理能力來調度訪問請求。這樣
能夠保證處理能力強的服務器能處理更多的訪問流量。調度器能夠自動詢問真實服務器的
負載狀況，並動態地調整其權值。
3.最少連接（Least Connections）
調度器經過「最少鏈接」調度算法動態地將網絡請求調度到已創建的連接數最少的服務器
上。若是集羣系統的真實服務器具備相近的系統性能，採用「最小鏈接」調度算法能夠較
好地均衡負載。
4.加權最少連接（Weighted Least Connections）
在集羣系統中的服務器性能差別較大的狀況下，調度器採用「加權最少連接」調度算法優
化負載均衡性能，具備較高權值的服務器將承受較大比例的活動鏈接負載。調度器能夠自
動詢問真實服務器的負載狀況，並動態地調整其權值。
5.基於局部性的最少連接（Locality-Based Least Connections）
「基於局部性的最少連接」調度算法是針對目標IP地址的負載均衡，目前主要用於Cache
集羣系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務
器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且
有服務器處於一半的工做負載，則用「最少連接」的原則選出一個可用的服務器，將請求
發送到該服務器。
6. 帶複製的基於局部性最少連接（ Locality-Based Least Connections with
Replication）
「帶複製的基於局部性最少連接」調度算法也是針對目標IP地址的負載均衡，目前主要
用於Cache集羣系統。它與LBLC算法的不一樣之處是它要維護從一個目標IP地址到一組服務
器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目
標IP地址找出該目標IP地址對應的服務器組，按「最小鏈接」原則從服務器組中選出一
臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按「最小鏈接
」原則從這個集羣中選出一臺服務器，將該服務器加入到服務器組中，將請求發送到該服
務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，
以下降複製的程度。
7.目標地址散列（Destination Hashing）
「目標地址散列」調度算法根據請求的目標IP地址，做爲散列鍵（Hash Key）從靜態分
配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，
不然返回空。
8.源地址散列（Source Hashing）
「源地址散列」調度算法根據請求的源IP地址，做爲散列鍵（Hash Key）從靜態分配的
散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，不然
返回空。
瞭解這些算法原理可以在特定的應用場合選擇最適合的調度算法，從而儘量地保持
Real Server的最佳利用性。固然也能夠自行開發算法，不過這已超出本文範圍，請參考有
關算法原理的資料。

4．一、什麼是高可用性
計算機系統的可用性(availability)是經過系統的可靠性(reliability)和可維護性
(maintainability)來度量的。工程上一般用平均無端障時間(MTTF)來度量系統的可靠性，
用平均維修時間（MTTR）來度量系統的可維護性。因而可用性被定義爲：
中科紅旗linux技術支持服務中心---西安站 http://linux.xab.ac.cn
×××西安網絡中心 中科紅旗linux培訓認證中心
MTTF/(MTTF+MTTR)*100%
業界根據可用性把計算機系統分爲以下幾類：
可用比例
(Percent
Availability)
年停機時間
(downtime/year
)
可用性分類
99.5 3.7天
常規系統
(Conventional)
99.9 8.8小時可用系統(Available)
99.99 52.6分鐘
高可用系統(Highly
Available)
99.999 5.3分鐘Fault Resilient
99.9999 32秒Fault Tolerant
爲了實現集羣系統的高可用性，提升系統的高可性，須要在集羣中創建冗餘機制。一個功
能全面的集羣機構以下圖所示

負載均衡服務器的高可用性
爲了屏蔽負載均衡服務器的失效，須要創建一個備份機。主服務器和備份機上都運行
High Availability監控程序，經過傳送諸如「I am alive」這樣的信息來監控對方的運
行情況。當備份機不能在必定的時間內收到這樣的信息時，它就接管主服務器的服務IP並
繼續提供服務；當備份管理器又從主管理器收到「I am alive」這樣的信息是，它就釋放
服務IP地址，這樣的主管理器就開開始再次進行集羣管理的工做了。爲在住服務器失效的
狀況下系統能正常工做，咱們在主、備份機之間實現負載集羣系統配置信息的同步與備份，
保持兩者系統的基本一致。
HA的容錯備援運做過程
自動偵測(Auto-Detect)階段 由主機上的軟件經過冗餘偵測線，經由複雜的監聽程序。邏
輯判斷，來相互偵測對方運行的狀況，所檢查的項目有：
主機硬件(CPU和周邊)
主機網絡
主機操做系統
數據庫引擎及其它應用程序
主機與磁盤陣列連線
爲確保偵測的正確性，而防止錯誤的判斷，可設定安全偵測時間，包括偵測時間間隔，
偵測次數以調整安全係數，而且由主機的冗餘通訊連線，將所聚集的訊息記錄下來，以供
維護參考。
自動切換(Auto-Switch)階段 某一主機若是確認對方故障，則正常主機除繼續進行原來的
任務，還將依據各類容錯備援模式接管預先設定的備援做業程序，並進行後續的程序及服
務。
自動恢復(Auto-Recovery)階段 在正常主機代替故障主機工做後，故障主機可離線進行修
復工做。在故障主機修復後，透過冗餘通信線與原正常主機連線，自動切換回修復完成的
主機上。整個回覆過程完成由EDI-HA自動完成，亦可依據預先配置，選擇回覆動做爲半自
動或不回覆。

4．二、HA三種工做方式：
（1）、主從方式 （非對稱方式）
工做原理：主機工做，備機處於監控準備情況；當主機宕機時，備機接管主機的一切工做，
待主機恢復正常後，按使用者的設定以自動或手動方式將服務切換到主機上運行，數據的
一致性經過共享存儲系統解決。

（2）、雙機雙工方式（互備互援）
工做原理：兩臺主機同時運行各自的服務工做且相互監測狀況，當任一臺主機宕機時，另
一臺主機當即接管它的一切工做，保證工做實時，應用服務系統的關鍵數據存放在共享存
儲系統中。
（3）、集羣工做方式（多服務器互備方式）
工做原理：多臺主機一塊兒工做，各自運行一個或幾個服務，各爲服務定義一個或多個備用
主機，當某個主機故障時，運行在其上的服務就能夠被其它主機接管。

相關文檔
http://tech.sina.com.cn/it/2004-04-09/1505346805.shtml
http://stonesoup.esd.ornl.gov
LINUX下的集羣實列應用
最近有客戶須要一個負載均衡方案，筆者對各類軟硬件的負載均衡方案進行了調查和
比較，從IBM sServer Cluster、Sun Cluster PlatForm 等硬件集羣，到中軟、紅旗、
TurboLinux的軟件集羣，發現不管採用哪一個廠商的負載均衡產品其價格都是該客戶目前所
不能接受的。因而筆者想到了開放源項目Linux Virtual Server(簡稱LVS)。通過對LVS的研
究和實驗，終於在Red Hat 9.0上用LVS成功地構架了一組負載均衡的集羣系統。整個實
現過程整理收錄以下，供讀者參考。
選用的LVS其實是一種Linux操做系統上基於IP層的負載均衡調度技術，它在操
做系統核心層上，未來自IP層的TCP/UDP請求均衡地轉移到不一樣的服務器，從而將一組
服務器構成一個高性能、高可用的虛擬服務器。使用三臺機器就能夠用LVS實現最簡單的集
羣，如圖1所示。

圖1 LVS實現集羣系統結構簡圖
圖1顯示一臺名爲Director的機器在集羣前端作負載分配工做；後端兩臺機器稱之爲
Real Server，專門負責處理Director分配來的外界請求。該集羣的核心是前端的Director
機器，LVS就是安裝在這臺機器上，它必須安裝Linux。Real Server則要根據其選用的負
載分配方式而定，一般Real Server上的設置比較少。接下來介紹Director機器上LVS的
安裝過程。
安裝
LVS的安裝主要是在Director機器上進行，Real Server只需針對不一樣的轉發方式作簡單
的設定便可。特別是對LVS的NAT方式，Real Server唯一要作的就是設一下缺省的網關。
因此構架集羣的第一步從安裝Director機器開始。
首先，要在Director機器上安裝一個Linux操做系統。雖然早期的一些Red Hat版本，
如6.二、7.二、8.0等自帶Red Hat本身的集羣軟件，或者是在內核中已經支持LVS，可是爲
了更清楚地瞭解LVS的機制，筆者仍是選擇自行將LVS編入Linux內核的方式進行安裝，
Linux版本採用Red Hat 9.0。
若是用戶對Red Hat的安裝比較瞭解，能夠選擇定製安裝，並只安裝必要的軟件包。
安裝中請選擇GRUB 作爲啓動引導管理軟件。由於GRUB 在系統引導方面的功能遠比
LILO強大，在編譯Linux內核時能夠體會它的方便之處。
LVS是在Linux內核中實現的，因此要對原有的Linux內核打上支持LVS的內核補丁，
而後從新編譯內核。支持LVS 的內核補丁能夠從LVS 的官方網
http://www.linuxvirtualserver.org 下載，下載時請注意使用的Linux核心版本，必須下載和

使用的Linux內核版本相一致的LVS內核補丁才行。對於Red Hat 9.0，其Linux內核版本
是2.4.20，因此對應內核補丁應該是 http://www.linuxvirtualserver.org/software/kernel-
2.4/linux-2.4.20-ipvs-1.0.9.patch.gz。筆者通過屢次實驗，使用Red Hat 9.0自帶的Linux
源代碼沒法成功編譯LVS 的相關模組。因爲時間關係筆者沒有仔細研究，而是另外從
kernel.org上下載了一個tar包格式的2.4.20內核來進行安裝，順利完成全部編譯。下面是
整個內核的編譯過程：
1.刪除Red Hat自帶的Linux源代碼
# cd /usr/src
# rm -rf linux*
2.下載2.4.20內核
# cd /usr/src
# wget ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.20.tar.bz2
3.解壓到當前目錄/usr/src
# cd /usr/src
# tar -xjpvf linux-2.4.20.tar.bz2
4.創建連接文件
# cd /usr/src # ln -s linux-2.4.20 linux-2.4 # ln -s linux-2.4.20 linux
5.打上LVS的內核補丁
# cd /usr/src
#wget http://www.linuxvirtualserver.org/software/kernel-2.4/linux-2.4.20-ipvs-
1.0.9.patch.gz
# gzip -cd linux-2.4.20-ipvs-1.0.9.patch.gz
# cd /usr/src/linux
# patch -p1 < ../linux-2.4.20-ipvs-1.0.9.patch
在打補丁時，注意命令執行後的信息，不能有任何錯誤信息，不然核心或模組極可能
沒法成功編譯。
6.打上修正ARP問題的內核補丁
# cd /usr/src
# wget http://www.ssi.bg/~ja/hidden-2.4.20pre10-1.diff
# cd /usr/src/linux

# patch -p1 < ../hidden-2.4.20pre10-1.diff
這一步在Director機器上能夠不作，可是在使用LVS/TUN和LVS/DR方式的Real Server
上必須作。
7.爲新核心命名
打開/usr/src/linux/Makefile。注意，在開始部分有一個變量EXTRAVERSION能夠自行定
義。修改這個變量，好比改爲「EXTRAVERSION=-LVS」後，編譯出的核心版本號就會顯
示成2.4.20-LVS。這樣給出有含義的名稱將有助於管理多個Linux核心。
8.檢查源代碼
# make mrproper
這一步是爲確保源代碼目錄下沒有不正確的.o文件及文件的互相依賴。由於是新下載的內
核，因此在第一次編譯時，這一步實際能夠省略。
9.配置核心選項
# make menuconfig
命令執行後會進入一個圖形化的配置界面，能夠經過這個友好的圖形界面對內核進行定製。
此過程當中，要注意對硬件驅動的選擇。Linux支持豐富的硬件，但對於服務器而言，用不到
的硬件驅動均可以刪除。另外，像Multimedia devices、Sound、Bluetooth support、Amateur
Radio support等項也能夠刪除。
注意，如下幾項配置對LVS很是重要，請確保做出正確的選擇：
(1)Code maturity level options項
對此項只有如下一個子選項，請選中爲*，即編譯到內核中去。
Prompt for development and/or incomplete code/drivers
(2)Networking options項
對此項的選擇能夠參考如下的配置，若是不清楚含義能夠查看幫助：
<*> Packet socket
[ ] Packet socket: mmapped IO
< > Netlink device emulation
Network packet filtering (replaces ipchains)
[ ] Network packet filtering debugging
Socket Filtering
<*> Unix domain sockets
TCP/IP networking
IP: multicasting
IP: advanced router
IP: policy routing
[ ] IP: use netfilter MARK value as routing key
[ ] IP: fast network address translation
<M> IP: tunneling
IP: broadcast GRE over IP
[ ] IP: multicast routing
[ ] IP: ARP daemon support (EXPERIMENTAL)
[ ] IP: TCP Explicit Congestion Notification support
[ ] IP: TCP syncookie support (disabled per default)
IP: Netfilter Configuration --->
IP: Virtual Server Configuration --->
(3)Networking options項中的IP: Virtual Server Configuration項
若是打好了LVS的內核補丁，就會出現此選項。進入Virtual Server Configuration選項，
有如下子選項：
<M> virtual server support (EXPERIMENTAL)
IP virtual server debugging
(12) IPVS connection table size (the Nth power of 2)
--- IPVS scheduler
<M> round-robin scheduling
<M> weighted round-robin scheduling
<M> least-connection scheduling scheduling
<M> weighted least-connection scheduling
<M> locality-based least-connection scheduling
<M> locality-based least-connection with replication scheduling
<M> destination hashing scheduling
<M> source hashing scheduling
<M> shortest expected delay scheduling
<M> never queue scheduling
--- IPVS application helper
<M> FTP protocol helper
以上全部項建議所有選擇。

(4)Networking options項中的IP: Netfilter Configuration項
對於2.4版本以上的Linux Kernel來講，iptables是取代早期ipfwadm和ipchains的
更好選擇，因此除非有特殊狀況須要用到對ipchains和ipfwadm的支持，不然就不要選它。
本文在LVS/NAT方式中，使用的就是iptables，故這裏不選擇對ipchains和ipfwadm的
支持：
< > ipchains (2.2-style) support
< > ipfwadm (2.0-style) support
10. 編譯內核
(1)檢查依賴關係
# make dep
確保關鍵文件在正確的路徑上。
(2)清除中間文件
# make clean
確保全部文件都處於最新的版本狀態下。
(3)編譯新核心
# make bzImage
(4)編譯模組
# make modules
編譯選擇的模組。
(5)安裝模組
# make modules_install
# depmod -a
生成模組間的依賴關係，以便modprobe定位。
(6)使用新模組
# cp System.map /boot/System.map-2.4.20-LVS
# rm /boot/System.map
# ln -s /boot/System.map-2.4.20-LVS /boot/System.map
# cp arch/i386/boot/bzImage /boot/vmlinuz-2.4.20-LVS
# rm /boot/vmlinuz
# ln -s /boot/vmlinuz-2.4.20-LVS /boot/vmlinuz
# new-kernel-pkg --install --mkinitrd --depmod 2.4.20-LVS

(7)修改GRUB，以新的核心啓動
執行完new-kernel-pkg命令後，GRUB的設置文件/etc/grub.conf中已經增長了新核心的
啓動項，這正是開始安裝Linux時推薦使用GRUB作引導程序的緣由。
grub.conf中新增內容以下：
title Red Hat Linux (2.4.20-LVS)
root (hd0,0)
kernel /boot/vmlinuz-2.4.20LVS ro root=LABEL=/
initrd /boot/initrd-2.4.20LVS.img
將Kernel項中的root=LABEL=/改爲 root=/dev/sda1 (這裏的/dev/sda1是筆者Linux的根
分區，讀者可根據本身的狀況進行不一樣設置）。
保存修改後，從新啓動系統:
# reboot
系統啓動後，在GRUB的界面上會出現Red Hat Linux(2.4.20-LVS)項。這就是剛纔編譯的
支持LVS的新核心，選擇此項啓動，看看啓動過程是否有錯誤發生。若是正常啓動，ipvs
將做爲模塊加載。同時應該注意到，用LVS的內核啓動後在/proc目錄中新增了一些文件，
好比/proc/sys/net/ipv4/vs/*。
11.安裝IP虛擬服務器軟件ipvsadm
用支持LVS的內核啓動後，便可安裝IP虛擬服務器軟件ipvsadm了。用戶能夠用tar包或
RPM 包安裝，tar 包能夠從如下地址 http://www.linuxvirtualserver.org/software/kernel-
2.4/ipvsadm-1.21.tar.gz 下載進行安裝。
這裏採用源RPM包來進行安裝：
# wget http://www.linuxvirtualserver.org/software/kernel-2.4/ipvsadm-1.21-7.src.rpm
# rpmbuild --rebuild ipvsadm-1.21-7.src.rpm
# rpm -ivh /usr/src/redhat/RPMS/i386/ipvsadm-1.21-7.i386.rpm
注意：高版本的rpm命令去掉了--rebuild這個參數選項，但提供了一個rpmbuild命令來實
現它。這一點和之前在Red Hat 6.2中以rpm—rebuild XXX.src.rpm來安裝源RPM包的習
慣作法有所不一樣。
安裝完，執行ipvsadm命令，應該有相似以下的信息出現：
# ipvsadm
IP Virtual Server version 1.0.9 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
出現相似以上信息，代表支持LVS 的內核和配置工具ipvsadm 已徹底安裝，這臺
Director機器已經初步安裝完成，已具有構架各類方式的集羣的條

實例
理解了上述關於請求轉發方式和調度算法的基本概念後，就能夠運用LVS來具體實現
幾種不一樣方式的負載均衡的集羣系統。LVS的配置是經過前面所安裝的IP虛擬服務器軟件
ipvsadm來實現的。ipvsadm與LVS的關係相似於iptables和NetFilter的關係，前者只是
一個創建和修改規則的工具，這些命令的做用在系統從新啓動後就消失了，因此應該將這
些命令寫到一個腳本里，而後讓它在系統啓動後自動執行。網上有很多配置LVS的工具，
有的甚至能夠自動生成腳本。可是本身手工編寫有助於更深刻地瞭解，因此本文的安裝沒
有利用其它第三方提供的腳本，而是純粹使用ipvsadm命令來配置。
下面就介紹一下如何配置LVS/NAT、LVS/TUN、LVS/DR方式的負載均衡集羣。
1.設定LVS/NAT方式的負載均衡集羣
NAT是指Network Address Translation，它的轉發流程是：Director機器收到外界請求，
改寫數據包的目標地址，按相應的調度算法將其發送到相應Real Server上，Real Server
處理完該請求後，將結果數據包返回到其默認網關，即Director機器上，Dire
參考資料： http://www.linuxpower.cn/bbs/read.php?tid=630&fpage=1