ntp時間服務同步

第一種方式：同步到網路時間伺服器

 # ntpdate time.windows.com
將硬體時間設定為當前系統時間。 
#hwclock –w 
加入crontab：    
30 8 * * * root /usr/sbin/ntpdate 192.168.0.1; /sbin/hwclock -w 每天的8:30將進行一次時間同步。
重啟crond服務：
service crond restart

第二種方式：同步到區域網內部的一臺時間同步伺服器
一、搭建時間同步伺服器
1、編譯安裝ntp server
rpm -qa | grep ntp
若沒有找到，則說明沒有安裝ntp包，從光碟上找到ntp包，使用
rpm -Uvh ntp***.rpm
進行安裝
2、修改ntp.conf配置檔案
vi /etc/ntp.conf
①、第一種配置：允許任何IP的客戶機都可以進行時間同步
將“restrict default nomodify notrap noquery”這行修改成：
restrict default nomodify notrap
配置檔案示例：/etc/ntp.conf
②、第二種配置：只允許192.168.211.***網段的客戶機進行時間同步
在restrict default nomodify notrap noquery（表示預設拒絕所有IP的時間同步）之後增加一行：
restrict 192.168.211.0 mask 255.255.255.0 nomodify notrap
3、啟動ntp服務
service ntpd start
開機啟動服務
chkconfig ntpd on
4、ntpd啟動後，客戶機要等幾分鐘再與其進行時間同步，否則會提示“no server suitable for synchronization found”錯誤。

二、配置時間同步客戶機
手工執行 ntpdate <ntp server> 來同步
或者利用crontab來執行
crontab -e
0 21 * * * ntpdate 192.168.211.22 >> /root/ntpdate.log 2>&1
每天晚上9點進行同步
附：
當用ntpdate -d 來查詢時會發現導致 no server suitable for synchronization found 的錯誤的資訊有以下2個：
錯誤1.Server dropped: Strata too high
在ntp客戶端執行ntpdate serverIP，出現no server suitable for synchronization found的錯誤。
在ntp客戶端用ntpdate –d serverIP檢視，發現有“Server dropped: strata too high”的錯誤，並且顯示“stratum 16”。而正常情況下stratum這個值得範圍是“0~15”。
這是因為NTP server還沒有和其自身或者它的server同步上。
以下的定義是讓NTP Server和其自身保持同步，如果在/ntp.conf中定義的server都不可用時，將使用local時間作為ntp服務提供給ntp客戶端。
server 127.127.1.0
fudge 127.127.1.0 stratum 8

在ntp server上重新啟動ntp服務後，ntp server自身或者與其server的同步的需要一個時間段，這個過程可能是5分鐘，在這個時間之內在客戶端執行ntpdate命令時會產生no server suitable for synchronization found的錯誤。
那麼如何知道何時ntp server完成了和自身同步的過程呢？
在ntp server上使用命令：
# watch ntpq -p
出現畫面：
Every 2.0s: ntpq -p                                                                                                             Thu Jul 10 02:28:32 2008
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
192.168.30.22   LOCAL(0)         8 u   22   64    1    2.113 179133.   0.001
LOCAL(0)        LOCAL(0)        10 l   21   64    1    0.000   0.000  0.001
注意LOCAL的這個就是與自身同步的ntp server。
注意reach這個值，在啟動ntp server服務後，這個值就從0開始不斷增加，當增加到17的時候，從0到17是5次的變更，每一次是poll的值的秒數，是64秒*5=320秒的時間。
如果之後從ntp客戶端同步ntp server還失敗的話，用ntpdate –d來查詢詳細錯誤資訊，再做判斷。
錯誤2.Server dropped: no data
從客戶端執行netdate –d時有錯誤資訊如下：
transmit(192.168.30.22) transmit(192.168.30.22)
transmit(192.168.30.22)
transmit(192.168.30.22)
transmit(192.168.30.22)
192.168.30.22: Server dropped: no data
server 192.168.30.22, port 123
.....
28 Jul 17:42:24 ntpdate[14148]: no server suitable for synchronization found出現這個問題的原因可能有2：
1。檢查ntp的版本，如果你使用的是ntp4.2（包括4.2）之後的版本，在restrict的定義中使用了notrust的話，會導致以上錯誤。
使用以下命令檢查ntp的版本：
# ntpq -c version
下面是來自ntp官方網站的說明：
The behavior of notrust changed between versions 4.1 and 4.2.
In 4.1 (and earlier) notrust meant "Don't trust this host/subnet for time".
In 4.2 (and later) notrust means "Ignore all NTP packets that are not cryptographically authenticated." This forces remote time servers to authenticate themselves to your (client) ntpd
解決：
把notrust去掉。
2。檢查ntp server的防火牆。可能是server的防火牆遮蔽了upd 123埠。
可以用命令
#service iptables stop

來關掉iptables服務後再嘗試從ntp客戶端的同步，如果成功，證明是防火牆的問題，需要更改iptables的設定。

namenode安全模式問題

當namenode發現叢集中的block丟失數量達到一個閥值時，namenode就進入安全模式狀態，不再接受客戶端的資料更新請求

在正常情況下，namenode也有可能進入安全模式：
    叢集啟動時（namenode啟動時）必定會進入安全模式，然後過一段時間會自動退出安全模式（原因是datanode彙報的過程有一段持續時間）
    
也確實有異常情況下導致的安全模式
    原因：block確實有缺失
    措施：可以手動讓namenode退出安全模式，bin/hdfs dfsadmin -safemode leave
          或者：調整safemode門限值：  dfs.safemode.threshold.pct=0.999f
    

HDFS冗餘資料塊的自動刪除

在日常維護hadoop叢集的過程中發現這樣一種情況：
    某個節點由於網路故障或者DataNode程序死亡，被NameNode判定為死亡，HDFS馬上自動開始資料塊的容錯拷貝；當該節點重新新增到叢集中時，由於該節點上的資料其實並沒有損壞，所以造成了HDFS上某些block的備份數超過了設定的備份數。通過觀察發現，這些多餘的資料塊經過很長的一段時間才會被完全刪除掉，那麼這個時間取決於什麼呢？
    該時間的長短跟資料塊報告的間隔時間有關。Datanode會定期將當前該結點上所有的BLOCK資訊報告給Namenode，引數dfs.blockreport.intervalMsec就是控制這個報告間隔的引數。
    hdfs-site.xml檔案中有一個引數：
<property>
    <name>dfs.blockreport.intervalMsec</name>
    <value>3600000</value>
    <description>Determines block reporting interval in milliseconds.</description>
</property>
    其中3600000為預設設定，3600000毫秒，即1個小時，也就是說，塊報告的時間間隔為1個小時，所以經過了很長時間這些多餘的塊才被刪除掉。通過實際測試發現，當把該引數調整的稍小一點的時候（60秒），多餘的資料塊確實很快就被刪除了。

hadoop安裝部署問題總結

1、hadoop啟動不正常
用瀏覽器訪問namenode的50070埠，不正常，需要診斷問題出在哪裡：
a、在伺服器的終端命令列使用jps檢視相關程序
（namenode1個節點   datanode3個節點   secondary namenode1個節點）
b、如果已經知道了啟動失敗的服務程序，進入到相關程序的日誌目錄下，檢視日誌，分析異常的原因
1）配置檔案出錯，saxparser  exception； ——找到錯誤提示中所指出的配置檔案檢查修改即可
2）unknown host——主機名不認識，配置/etc/hosts檔案即可，或者是配置檔案中所用主機名跟實際不一致
   （注：在配置檔案中，統一使用主機名，而不要用ip地址）
3）directory 訪問異常—— 檢查namenode的工作目錄，看許可權是否正常

start-dfs.sh啟動後，發現有datanode啟動不正常
a）檢視datanode的日誌，看是否有異常，如果沒有異常，手動將datanode啟動起來
sbin/hadoop-daemon.sh start datanode
b）很有可能是slaves檔案中就沒有列出需要啟動的datanode
c）排除上述兩種情況後，基本上，能在日誌中看到異常資訊：
   1、配置檔案
   2、ssh免密登陸沒有配置好
   3、datanode的身份標識跟namenode的叢集身份標識不一致（刪掉datanode的工作目錄）

datanode節點超時時間設定

datanode程序死亡或者網路故障造成datanode無法與namenode通訊，namenode不會立即把該節點判定為死亡，要經過一段時間，這段時間暫稱作超時時長。HDFS預設的超時時長為10分鐘+30秒。如果定義超時時間為timeout，則超時時長的計算公式為：
    timeout  = 2 * heartbeat.recheck.interval + 10 * dfs.heartbeat.interval。
    而預設的heartbeat.recheck.interval 大小為5分鐘，dfs.heartbeat.interval預設為3秒。
    需要注意的是hdfs-site.xml 配置檔案中的heartbeat.recheck.interval的單位為毫秒，dfs.heartbeat.interval的單位為秒。所以，舉個例子，如果heartbeat.recheck.interval設定為5000（毫秒），dfs.heartbeat.interval設定為3（秒，預設），則總的超時時間為40秒。
    hdfs-site.xml中的引數設定格式：

<property>
        <name>heartbeat.recheck.interval</name>
        <value>2000</value>
</property>
<property>
        <name>dfs.heartbeat.interval</name>
        <value>1</value>
</property>