互聯網 - 大數據

文章出處
SQL Server的AlwaysOn錯誤19456和41158
 
最近在公司搞異地數據庫容災，使用AlwaysOn的異地節點進行數據同步，在搭建的過程中遇到了一些問題
軟件版本
SQL Server2014
Windows2012R2
 
網絡環境
兩個機房，一個機房是一個網段，另一個機房是另一個網段，也就是兩個子網，兩個網段，但是在同一個域中，而且使用了VPN
 
AlwaysOn是支持多子網的，在跨機房，多子網環境有幾個地方需要注意
1、在搭建過程中需要把異地節點的投票權去掉，這個在搭建過程中沒有遇到問題
NodeWeight
在任意集群節點上以域用戶登錄計算機，并以管理員身份運行powershell，并執行下面命令，JXxx08為異地節點的計算機名，把JXxx08節點的投票權設置為0
命令如下

Import-Module FailoverClusters
$node ="JXxx08"
(Get-ClusterNode $node).NodeWeight = 0
$cluster = (Get-ClusterNode $node).Cluster
$nodes = Get-ClusterNode -Cluster $cluster
$nodes | Format-Table -property NodeName, State, NodeWeight

 
 
2、由于可用性組建立了偵聽器，那么在failover的時候會遇到偵聽器IP不能覆蓋另一個子網的問題，導致報錯
無法將實例xxx聯接到可用性組xxx
服務器“xxxxxx”無法承載為可用性組偵聽器配置的任何 IP 地址。或者配置可承載指定 IP 地址之一的公共群集網絡，或者添加可在此服務器的公共群集網絡上承載的另一個偵聽器 IP 地址。
無法將本地可用性副本聯接到可用性組“xxxxxx”。該操作遇到了 SQL Server 錯誤 19456，已被回滾。有關詳細信息，請查看 SQL Server 錯誤日志。在錯誤根源得到糾正后，請重試 ALTER AVAILABILITY GROUP JOIN 命令。 (Microsoft SQL Server，錯誤: 19456)
解決這個問題的方法是在偵聽器里再添加另一個網段的vip
這樣偵聽器現在有兩個網段的vip了，異地機房的偵聽器IP在添加之后會自動脫機，不用理會它
 
3、由于是新添加的異地節點，添加到已有的可用性組中，那么可能遇到下面這個報錯
無法將實例xxx聯接到可用性組xxx
無法將可用性副本聯接到可用性組xx，該操作遇到了SQL Server錯誤41106，已被回滾。
有關詳細信息，請查看 SQL Server 錯誤日志。在錯誤根源得到糾正后，請重試 ALTER AVAILABILITY GROUP JOIN 命令。 (Microsoft SQL Server，錯誤: 41158)
這個問題跟多子網無關，在這里也順便列出來了
解決方法是再隨便新建一個AG，把異地節點也加入到這個AG里面，就可以解決
因為異地節點是新建進來的節點，AlwaysOn的鏡像端點還沒有設置才導致報上面的錯誤
 
 
希望這篇文章能幫助大家
 
如有不對的地方，歡迎大家拍磚o(∩_∩)o 
本文版權歸作者所有，未經作者同意不得轉載。

文章出處
Alwayson的IP沖突
 
https://social.technet.microsoft.com/Forums/office/en-US/4d50cb1c-eef7-4dcc-b937-3c8eb0b5565c/failover-cluster-issue-ip-conflict?forum=winserverClustering
 
http://serverfault.com/questions/281025/failover-cluster-failed-to-failover-due-to-mysterious-ip-conflict
 
https://blogs.technet.microsoft.com/askcore/2010/02/22/windows-server-2008-failover-clusters-networking-part-2/

文章出處
logstash服務啟動腳本
最近在弄ELK，發現logstash沒有sysv類型的服務啟動腳本，于是按照網上一個老外提供的模板自己進行修改

#添加用戶
useradd logstash -M -s /sbin/nologin
mkdir /var/log/logstash/
chown -R logstash:logstash /var/log/logstash/
chown -R logstash:logstash /usr/local/logstash-2.0.0/

 

 

vi /etc/init.d/logstash
#!/bin/sh
# Init script for logstash
# Maintained by Elasticsearch
# Generated by pleaserun.
# Implemented based on LSB Core 3.1:
# * Sections: 20.2, 20.3
#
### BEGIN INIT INFO
# Provides: logstash
# Required-Start: $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description:
# Description: Starts Logstash as a daemon.
### END INIT INFO

PATH=/sbin:/usr/sbin:/bin:/usr/bin
export PATH

if [ `id -u` -ne 0 ]; then
echo "You need root privileges to run this script"
exit 1
fi

name=logstash
pidfile="/var/run/$name.pid"

LS_USER=logstash
LS_GROUP=logstash
LS_HOME=/var/lib/logstash
LS_HEAP_SIZE="500m"
LS_LOG_DIR=/var/log/logstash
LS_LOG_FILE="${LS_LOG_DIR}/$name.log"
LS_CONF_DIR=/etc/logstash/conf.d
LS_OPEN_FILES=16384
LS_NICE=19
LS_OPTS=""

[ -r /etc/default/$name ] && . /etc/default/$name
[ -r /etc/sysconfig/$name ] && . /etc/sysconfig/$name

program=/opt/logstash/bin/logstash
args="agent -f ${LS_CONF_DIR} -l ${LS_LOG_FILE} ${LS_OPTS}"

start() {

LS_JAVA_OPTS="${LS_JAVA_OPTS} -Djava.io.tmpdir=${LS_HOME}"
HOME=${LS_HOME}
export PATH HOME LS_HEAP_SIZE LS_JAVA_OPTS LS_USE_GC_LOGGING

# chown doesn't grab the suplimental groups when setting the user:group - so we have to do it for it.
# Boy, I hope we're root here.
SGROUPS=$(id -Gn "$LS_USER" | tr " " "," | sed 's/,$//'; echo '')

if [ ! -z $SGROUPS ]
then
EXTRA_GROUPS="--groups $SGROUPS"
fi

# set ulimit as (root, presumably) first, before we drop privileges
ulimit -n ${LS_OPEN_FILES}

# Run the program!
nice -n ${LS_NICE} chroot --userspec $LS_USER:$LS_GROUP $EXTRA_GROUPS / sh -c "
cd $LS_HOME
ulimit -n ${LS_OPEN_FILES}
exec \"$program\" $args
" > "${LS_LOG_DIR}/$name.stdout" 2> "${LS_LOG_DIR}/$name.err" &

# Generate the pidfile from here. If we instead made the forked process
# generate it there will be a race condition between the pidfile writing
# and a process possibly asking for status.
echo $! > $pidfile

echo "$name started."
return 0
}

stop() {
# Try a few times to kill TERM the program
if status ; then
pid=`cat "$pidfile"`
echo "Killing $name (pid $pid) with SIGTERM"
kill -TERM $pid
# Wait for it to exit.
for i in 1 2 3 4 5 ; do
echo "Waiting $name (pid $pid) to die..."
status || break
sleep 1
done
if status ; then
if [ "$KILL_ON_STOP_TIMEOUT" -eq 1 ] ; then
echo "Timeout reached. Killing $name (pid $pid) with SIGKILL. This may result in data loss."
kill -KILL $pid
echo "$name killed with SIGKILL."
else
echo "$name stop failed; still running."
fi
else
echo "$name stopped."
fi
fi
}

status() {
if [ -f "$pidfile" ] ; then
pid=`cat "$pidfile"`
if kill -0 $pid > /dev/null 2> /dev/null ; then
# process by this pid is running.
# It may not be our pid, but that's what you get with just pidfiles.
# TODO(sissel): Check if this process seems to be the same as the one we
# expect. It'd be nice to use flock here, but flock uses fork, not exec,
# so it makes it quite awkward to use in this case.
return 0
else
return 2 # program is dead but pid file exists
fi
else
return 3 # program is not running
fi
}

force_stop() {
if status ; then
stop
status && kill -KILL `cat "$pidfile"`
fi
}

case "$1" in
start)
status
code=$?
if [ $code -eq 0 ]; then
echo "$name is already running"
else
start
code=$?
fi
exit $code
;;
stop) stop ;;
force-stop) force_stop ;;
status)
status
code=$?
if [ $code -eq 0 ] ; then
echo "$name is running"
else
echo "$name is not running"
fi
exit $code
;;
restart)

stop && start
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|force-stop|status|restart}" >&2
exit 3
;;
esac

exit $?

 

chmod +x /etc/init.d/logstash
#設置開機啟動
chkconfig --add logstash
chkconfig logstash on

 
 
 
如有不對的地方，歡迎大家拍磚o(∩_∩)o 
本文版權歸作者所有，未經作者同意不得轉載。

文章出處
Hyper-V上運行的Linux虛擬機驗證是否安裝了集成服務
 
 
ps aux|grep "hv"
root       311  0.0  0.0      0     0 ?        S    Sep07   0:00 [hv_vmbus_con/0]
root       312  0.0  0.0      0     0 ?        S    Sep07   0:00 [hv_vmbus_con/1]
root       313  0.0  0.0      0     0 ?        S    Sep07   0:00 [hv_vmbus_con/2]
root       314  0.0  0.0      0     0 ?        S    Sep07   0:00 [hv_vmbus_con/3]
root       315  0.0  0.0      0     0 ?        S    Sep07   0:00 [hv_vmbus_ctl/0]
root       316  0.0  0.0      0     0 ?        S    Sep07   0:00 [hv_vmbus_ctl/1]
 
在虛擬機里運行上面的命令，如果有[hv_vmbus_con/0]輸出表示已經安裝了Linux集成服務
 
如有不對的地方，歡迎大家拍磚o(∩_∩)o 
本文版權歸作者所有，未經作者同意不得轉載。

文章出處
Windows2012R2備用域控搭建
 
前置操作
域控
主域控的主dns：自己的ip，備dns：備域控的ip
備域控的主dns：自己的ip，備dns：主域控的ip
客戶端
主dns：主域控的ip，備dns：備域控的ip
 
一般說主和備，主要是指擔任PDC放置的角色的這臺DC，所有修改密碼的操作必須由這臺DC應答
除了修改密碼、域管理、林管理，其他操作（主要是身份驗證）都可以隨便抓一臺DC來完成
DNS是一個列表，在整個林里面同步，除了PDC放置有單獨的列表，其它DC一般沒有權重
也就是PDC故障，如果不需要修改用戶的密碼，可以不用管
 
 
備用域控端
1、配置域控ip，ipv6去掉，禁用TCP/IP上的NetBIOS，首選DNS服務器填寫：192.168.1.20
192.168.1.20是主域控的IP地址，因為要發現當前環境中的域，那么DNS就要指向主域控的IP地址
 
 
 
 
2、安裝AD域服務
 
 
 
 安裝AD域服務的同時，操作系統會同時安裝好DNS服務器
3、點擊服務器管理器右上角的小旗幟，彈出對話框，點擊“將此服務器提升為域控制器”以提升為域控
 
4、手動輸入域名，這里不要點擊選擇按鈕，直接輸入windows域的域名即可
輸入域用戶和密碼
5、輸入目錄服務還原模式DSRM密碼
 
6、直接下一步
 
7、直接下一步，復制自這里保持默認即可，也就是“任何域控制器”
 
8、直接下一步
 
9、直接下一步
 
10、開始安裝，安裝過程中會突然斷網，大概需要等5分鐘，重新遠程服務器即可
 
11、打開DNS管理器，可以看到機器名和IP信息都已經同步過來了，同步間隔默認是15分鐘
 
 
 
如有不對的地方，歡迎大家拍磚o(∩_∩)o 
本文版權歸作者所有，未經作者同意不得轉載。

文章出處
主域控角色遷移和奪取（轉載）
轉載自：http://yupeizhi.blog.51cto.com/3157367/1427978
 
操作系統版本：Windows2012R2 數據中心版
 
 
FSMO角色遷移
主域控沒有掛的情況下使用FSMO角色遷移
FSMO角色遷移步驟，下面步驟在備用域控上執行
0、使用管理員身份打開powershell控制臺
1、輸入ntdsutil.exe
2、輸入roles 管理 NTDS 角色所有者令牌
3、輸入Connections 連接到一個特定 AD DC/LDS 實例
4、輸入Connect to server %s 連接到服務器，%s備用域控的FQDN全稱，我這里是dc3.abc.com
5、輸入quit 返回到上一個菜單
6、輸入Transfer infrastructure master 將已連接的服務器定為結構主機
7、輸入Transfer naming master 使已連接的服務器成為命名主機
8、輸入Transfer PDC 將已連接的服務器定為 PDC
9、輸入Transfer RID master 將已連接的服務器定為 RID 主機
10、輸入Transfer schema master 將已連接的服務器定為架構主機
11、輸入quit 返回到上一個菜單
12、輸入quit 退出
注意：每次彈出對話框都選擇“是”即可
到這里，角色轉移算是完成了，你可以通過命令查看角色，確定角色已經全部轉移。
13、輸入netdom query fsmo 查看FSMO角色
 
 
 
 
FSMO角色奪取
主域控已經掛了并且無法恢復的情況下使用FSMO角色奪取
當主域服務器可以正常連接的時候，我們可以通過角色遷移的方法遷移角色，但如果主域出了故障或宕機了，并且永遠也恢復不了，那我們就需要在輔助域控制器上面通過角色奪取，奪取FSMO角色
FSMO角色奪取步驟，下面步驟在備用域控上執行
0、使用管理員身份打開powershell控制臺
1、輸入ntdsutil.exe
2、輸入roles                  管理 NTDS 角色所有者令牌
3、輸入Connections                連接到一個特定 AD DC/LDS 實例
4、輸入Connect to server %s               連接到服務器，%s備用域控FQDN全稱，我這里是dc3.abc.com
5、輸入quit                     返回到上一個菜單
6、輸入Seize infrastructure master              在已連接的服務器上覆蓋結構角色
7、 輸入Seize naming master                      覆蓋已連接的服務器上的命名主機角色
8、輸入Seize PDC                               在已連接的服務器上覆蓋 PDC 角色
9、輸入Seize RID master                      在已連接的服務器上覆蓋 RID 角色
10、輸入Seize schema master                 在已連接的服務器上覆蓋架構角色
11、輸入quit                                        返回到上一個菜單
12、輸入quit                                       退出
 
注意：每次彈出對話框都選擇“是”即可
到這里，角色奪取算是完成了，你可以通過命令查看角色，確定角色已經全部轉移。
13、netdom query fsmo 查看FSMO角色
 
 
在FSMO角色遷移和奪取成功之后，原來的主域控會自動降級為備用域控，并從現在的主域控同步數據
 
 
相關文章：
Active Directory 禁用客戶端緩存登陸
http://yupeizhi.blog.51cto.com/3157367/1678443/
 

文章出處
基于本地存儲的kvm虛擬機在線遷移
 
kvm虛擬機遷移分為4種
（1）熱遷移基于共享存儲
（2）熱遷移基于本地存儲
（3）冷遷移基于共享存儲
（4）冷遷移基于本地存儲
這里介紹的是基于本地存儲的熱遷移
動態塊遷移版本要求
qemu版本要求  大于或等于0.12.1（centos6.7或以上都沒問題）
rpm -qa|grep qemu
qemu-kvm-0.12.1.2-2.491.el6_8.1.x86_64
qemu-kvm-tools-0.12.1.2-2.491.el6_8.1.x86_64
目標宿主機：192.168.1.24  機器名：CQ-KVM01
源宿主機：192.168.1.26   機器名：CQ-KVM02
遷移使用tcp認證方式
kvm虛擬機名稱，是一臺跑nginx的虛擬機：CQ-NGINX01
1、配置libvirtd服務 源宿主機和目標宿主機都要執行
vi /etc/libvirt/libvirtd.conf
listen_tls = 0   
listen_tcp = 1
tcp_port = "16509"
listen_addr = "0.0.0.0"
auth_tcp = "none"
mdns_adv = 0
解釋
listen_tls：關閉tls，默認是開啟的
listen_tcp ：開啟tcp認證
tcp_port：tcp端口配置，默認端口是16509
auth_tcp：配置是否開啟口令認證，默認不開啟
mdns_adv：是否開啟mdns組播，默認關閉
sed -i 's/^#listen_tls = 0/listen_tls = 0/' /etc/libvirt/libvirtd.conf
sed -i 's/^#listen_tcp = 1/listen_tcp = 1/' /etc/libvirt/libvirtd.conf
sed -i 's/^#tcp_port = \"16509\"/tcp_port = \"16509\"/' /etc/libvirt/libvirtd.conf
sed -i 's/^#listen_addr = \"192.168.0.1\"/listen_addr = \"0.0.0.0\"/' /etc/libvirt/libvirtd.conf
sed -i 's/^#auth_tcp = \"sasl\"/auth_tcp = \"none\"/' /etc/libvirt/libvirtd.conf
sed -i 's/^#mdns_adv = 1/mdns_adv = 0/' /etc/libvirt/libvirtd.conf
cat libvirtd.conf |grep -iE "listen_tls"
cat libvirtd.conf |grep -iE "listen_tcp"
cat libvirtd.conf |grep -iE "tcp_port"
cat libvirtd.conf |grep -iE "listen_addr"
cat libvirtd.conf |grep -iE "auth_tcp"
cat libvirtd.conf |grep -iE "mdns_adv"
2、配置libvirtd監聽方式，無論是tcp，ssh，tls認證方式都需要配置 ， 源宿主機和目標宿主機都要執行
vi /etc/sysconfig/libvirtd
LIBVIRTD_ARGS="--listen"
3、編輯/etc/libvirt/qemu.conf文件  源宿主機和目標宿主機都要執行
vi /etc/libvirt/qemu.conf
vnc_listen = "0.0.0.0"
解釋
vnc_listen：使虛擬機帶外VNC默認監聽.0.0.0.0
4、重啟libvirtd服務，使配置生效，  源宿主機和目標宿主機都要執行
/etc/init.d/libvirtd restart
5、檢查端口和進程，libvirtd是否監聽16509端口，  源宿主機和目標宿主機都要執行
netstat -lntp | grep libvirtd
tcp        0      0 0.0.0.0:16509               0.0.0.0:*                   LISTEN      48825/libvirtd    
修改iptables腳本，放行16509端口和49152端口
#ACCESS kvm
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 5900:5909 -j ACCEPT
iptables -A INPUT -p tcp --dport 16509 -j ACCEPT
iptables -A INPUT -p tcp --dport 49152 -j ACCEPT
6、在源宿主機和目標宿主機加上IP和主機的解析
#24機器上
echo "192.168.1.26 CQ-KVM02"  >> /etc/hosts
#26機器上
echo "192.168.1.24 CQ-KVM01"  >> /etc/hosts
7、在源宿主機連接目標宿主機的libvirtd并查看虛擬機信息
virsh -c qemu+tcp://root@192.168.1.26:16509/system
virsh -c qemu+tcp://root@192.168.1.24:16509/system
8、在目標宿主機創建同樣大小的鏡像文件，路徑、名稱也要一樣
要加上preallocation=metadata，否則使用virt-install命令安裝完成后虛擬機磁盤鏡像會變為raw格式
qemu-img create -f qcow2  -o preallocation=metadata  /data/kvmimg/CQ-NGINX01.qcow2 100G
9、遷移 ，192.168.1.26為目標宿主機的內網IP，tcp認證方式，遷移時間有點長需要開一個screen窗口，不需要cd 到鏡像文件所在目錄
screen -S migratekvm
virsh migrate --live --copy-storage-all --unsafe --persistent  CQ-NGINX01  qemu+tcp://root@192.168.1.26:16509/system
10、在目標宿主機執行，會顯示paused狀態 即是suspended狀態
watch virsh list --all
11、在目標宿主機執行，顯示遷移進度
tailf /var/log/libvirt/qemu/CQ-NGINX01.log
12、在目標宿主機執行，鏡像文件目錄為/data/kvmimg/，顯示虛擬機鏡像的大小，會看到虛擬機鏡像會不斷增大表示數據已經在遷移過來
注意創建鏡像文件的時候要使用preallocation=metadata
cd /data/kvmimg/
watch du -h *
13、虛擬機遷移完成后，源宿主機為關機狀態，目標宿主機變為running狀態
virsh list --all #源宿主機
virsh list --all #目標宿主機
14、源宿主機刪除xml配置文件
virsh destroy CQ-NGINX01
virsh undefine CQ-NGINX01
注意：
遷移過程中ping會有卡頓，有時會丟幾個包，如果虛擬機中有部署數據庫，應用程序最好有重連機制
回遷方法
建議不要刪除源宿主機上的鏡像文件，保留鏡像文件
#在目標宿主機上執行 ，回遷到源宿主機
virsh dumpxml CQ-NGINX01  >~/CQ-NGINX01.xml
virsh migrate --live --copy-storage-all --unsafe --persistent CQ-NGINX01  qemu+tcp://root@192.168.1.24:16509/system
注意：
源宿主機和目標宿主機最好要保持硬件一致 ，這樣遷移和回遷出問題的幾率才能降到最低！
遷移速度和成功率和網絡有很大關系，宿主機的網絡盡量是萬兆或千兆多網卡綁定，可以提高遷移速度和成功率
#限制遷移速度 為600M/s
virsh migrate-setspeed  CQ-NGINX01  600

---

在線遷移問題匯總
（如果ssh的端口不是默認22，可以寫為 qemu+ssh://target:port/system）
Question 1:
error: internal error hostname on destination resolved to localhost, but migration requires an FQDN
解決辦法很簡單，因為默認情況下hostname 是 localhost，我們需要把目標的hostname修改一下，臨時的也可以。
#hostname target
Question 2:
error: internal error Attempt to migrate guest to the same host 00020003-0004-0005-0006-000700080009
這個在mail list 中有大牛說是服務器提供商的問題，
你可以用#dmidecode -s system-uuid 查看一下這個ID，理論上是#virsh sysinfo | grep uuid 及# virsh capabilities | grep uuid
這三個ID是一樣的。（之前看論壇里發的解決方法是需要下載一個dmidecode 命令的文件去替換系統的，達到修改的目的，不過我只是修改了libvirt的配置文件就可以了，可能是版本的問題）
我們修改一下libvirtd的配置文件
#sed -i "/#host_uuid/ahost_uuid = \"`uuidgen`\"" /etc/libvirt/libvirtd.conf
重啟一下libvirtd 服務
# /etc/init.d/libvirtd restart
然后再查看一下
# virsh capabilities | grep uuid
Question 3:
error: unable to set user and group to '107:107' on '/image/vmtest/disk.img': No such file or directory
如果順利進入到這步的話，就很簡單了，沒有directory 直接創建一個就可以，沒有disk.img 直接create一個
注：創建的磁盤應該和源虛擬機的磁盤是一樣的大小（更大應該是可以）和格式（raw還是qcow2）
qemu-img create /image/vmtest/disk.img +sizeG
Question 4:
error: Unable to resolve address 'target' service '49155': Name or service not known
《《Name or service not known》》在/etc/hosts 添加解析的ip和target的域名即可
Question 5:
virsh migrate --live --copy-storage-all --unsafe --persistent CQ-NGINX01  qemu+tcp://root@192.168.1.24:16509/system
error: Unable to read from monitor: Connection reset by peer
可能目標宿主機和源宿主機內存不夠
建議：目標宿主機和源宿主機上都關閉一些不必要的虛擬機把內存騰出來
也可以清空cache把內存騰出來
#清除cache 首先執行sync命令
sync
echo 3 > /proc/sys/vm/drop_caches

---

基于TCP認證方式的遷移（需要輸入用戶名和密碼）
步驟跟上面大致相同，只是有些步驟需要做相應變更
 
1、配置libvirtd服務 源宿主機和目標宿主機都要執行，auth_tcp使用sasl認證方式
vi /etc/libvirt/libvirtd.conf
auth_tcp = "sasl"
sed -i 's/^#auth_tcp = \"sasl\"/auth_tcp = \"sasl\"/' /etc/libvirt/libvirtd.conf
 
 
2、創建libvirt管理用戶virtadmin
saslpasswd2 -a libvirt virtadmin
Password:
Again (for verification):
用戶名：virtadmin
密碼：xxxxxxx
可以使用sasldblistuser2命令查看創建了那些用戶：
sasldblistusers2 -f /etc/libvirt/passwd.db
 
7、在源宿主機連接目標宿主機的libvirtd并查看虛擬機信息，會詢問用戶和密碼，輸入saslpasswd2命令創建的用戶virtadmin和密碼即可
virsh -c qemu+tcp://root@192.168.1.26:16509/system
Please enter your authentication name: virtadmin
Please enter your password:
Welcome to virsh, the virtualization interactive terminal.
9、遷移 ，192.168.1.26為目標宿主機的內網IP，tcp認證方式，遷移時間有點長需要開一個screen窗口，不需要cd 到鏡像文件所在目錄，
同樣輸入saslpasswd2 命令創建的用戶virtadmin和密碼即可
screen -S migratekvm
virsh migrate --live --copy-storage-all --unsafe --persistent CQ-NGINX01 qemu+tcp://root@192.168.1.26:16509/system
Please enter your authentication name: virtadmin
Please enter your password:
 

文章出處
SQL Server 數據加密功能解析
 
轉載自: 騰云閣 https://www.qcloud.com/community/article/194
數據加密是數據庫被破解、物理介質被盜、備份被竊取的最后一道防線，數據加密，一方面解決數據被竊取安全問題，另一方面有關法律要求強制加密數據。SQL Server 的數據加密相較于其他數據庫，功能相對完善，加密方法較多。通常來講，數據加密分為對稱加密和非對稱加密。對稱加密：加密與解密使用同一密鑰，密鑰需要傳輸，安全性較弱，但性能較非對稱要好。非對稱加密：加密與解密使用不同密鑰（公鑰和私鑰），較對稱密鑰安全性較好，但是算法較復雜，帶來性能上的損失。因此，折中的方法是使用對稱密鑰加密數據，使用非對稱密鑰加密對稱密鑰。這樣既保證高性能，又提高密鑰的可靠性。
同樣，SQL Server 就使用了折中的方法，所以SQL Server 加密功能包含2個部分：數據加密和密鑰管理
 
 
一.數據加密
說道數據加密，我們不得不說下加密算法，SQL Server支持多種加密算法：
 
二.密鑰管理
1.SQL Server加密層次結構
由圖可以看出，加密是分層級的。每一個數據庫實例都擁有一個服務主密鑰(Service Master Key),這個密鑰是實例的根密鑰，在實例安裝的時候自動生成,其本身由Windows提供的數據保護API進行保護(Data Pertection API)，服務主密鑰除了為其子節點提供加密服務之外，還用于加密一些實例級別的信息，比如實例的登錄名密碼或者鏈接服務器的信息。
在服務主密鑰之下的是數據庫主密鑰（Database Master Key），這個密鑰由服務主密鑰進行加密。這是一個數據庫級別的密鑰，可以用于為創建數據庫級別的證書或非對稱密鑰提供加密，每一個數據庫只能有一個數據庫主密鑰。
EKM模塊，這個比較特別，全稱可擴展密鑰管理模塊，該功能增強sqlserver密鑰管理的能力，允許將密鑰存儲到數據庫之外，包括一些硬件，如智能卡、USB設備或硬件安全模塊（HSM）；并且允許使用第三方產品來管理密鑰和進行加密；另外，有條件的可以使用更高性能的HSM模塊來加解密，減少加解密上性能的損失。
 
2.SQL Server加密方式
對象定義加密
未保證觸發器、存儲過程、視圖等定義信息，我們可以在定義sqlserver對象的時候添加WITH ENCRYPTION字段來加密對象。
 
列數據加密
通過函數加密表中的某一列數據。可以通過密碼、對稱密鑰、非對稱密鑰、證書等4中方式加密。其中，還包括 帶有驗證器的加密函數，驗證器用來解決密文替換問題，驗證器一般選用不更改獨一無二的id，這樣就算密文替換，驗證器不對，一樣失敗。
 
連接加密
通過證書的方式對ssl連接加密，一般用于鏡像，客戶端和SQL Server之間的連接就是通過這種方式，防止黑客竊取客戶端和數據庫之間的發送的數據。
 
TDE透明數據加密(2008)
透明數據加密，顧名思義，是在用戶不感知的情況下完成加解密操作。
它的加密是在頁級別進行，是在寫入磁盤前加密，讀入內存時解密，針對數據和日志文件，做到實時I/O加密，并且備份文件也會一同加密。
密鑰存在數據庫引導記錄中，收到證書或者非對稱密鑰的保護，也可以與EKM模塊一同使用。官方說法，額外占用3%-5%的cpu資源。
TDE也有一些缺點：
壓縮率小，由于它是先加密再壓縮的，所以無法顯著壓縮備份。
備份同樣是加密的，所有恢復的時候要小心，注意備份證書和密鑰，才能在另個實例中還原數據庫
性能有一定損耗
 
備份加密(2014)
支持備份的過程中進行加密，并且支持先壓縮在加密，保持高壓縮比，打破了使用透明數據加密后幾乎沒有壓縮率的窘境。
因此，使用原生備份加密無論在將數據備份到異地數據中心，還是將數據備份到云端，都能夠以非常低的成本對數據提供額外的安全保障。
 
全程加密AlwaysEncrypted（2016）
全程加密，數據永遠是加密狀態，你可以在加密數據上執行操作，無需先對它們解密，也就是說加密的敏感信息不會有機會變為明文。
全程加密針對列做處理，在創建列主密鑰，列加密密鑰后，可以在創建表的時候設置列加密。
加密模式分為兩種：確定型加密與隨機型加密。
確定型加密能夠確保對某個值加密后的結果是始終相同的，這就允許使用者對該數據列進行等值比較、連接及分組操作。確定型加密的缺點在于有可能揣測出原文，而隨機型加密能夠保證某個給定值在任意兩次加密后的結果總是不同的，從而杜絕了猜出原值的可能性。官方建議需要搜索和分組的列使用確定性加密，而注釋和其他敏感不會進行搜索分組的信息使用隨機性加密。
 

文章出處
最近幫客戶實施的基于SQL Server AlwaysOn跨機房切換項目
 
最近一個來自重慶的客戶找到走起君，客戶的業務是做移動互聯網支付，是微信支付收單渠道合作伙伴，數據庫里存儲的是支付流水和交易流水。
由于客戶那邊沒有DBA，所以找到走起君商量一個數據庫服務器搬遷項目。
 
 

---

項目背景
客戶需要把在10樓的服務器全部搬到15樓，而且需要在有限的停機時間之內，客戶使用的數據庫是SQL Server2008R2，Windows2008R2
 
客戶的兩個重要要求
1、總停機時間少于10分鐘
2、數據不能有任何丟失
 
 
 

---

出方案
針對這兩個要求，SQL Server有哪些可以選擇的方案呢？
 
方案一 復制
使用復制，當前客戶環境已經有一套數據庫復制在跑，10樓的發布庫不動，在15樓增加一個訂閱庫，數據復制到15樓，但是復制有一個致命點：不保證數據一致性，因為復制是異步的
復制只能滿足要求一，不能滿足要求二，只能拋棄這個方案
 
方案二 日志備份
在15樓增加一臺數據庫服務器，10樓的發布庫做完整備份還原到15樓的數據庫，然后在搬遷的時候追加一個日志備份，并還原到15樓的數據庫服務器
日志備份保存的數據是完整備份到日志備份這個時間段的數據，由于每天寫入的變更數據量比較大，導致ldf文件也比較大，達到40G+，在測試過程中
發現，kill掉數據庫所有連接-》設置數據庫為只讀模式-》備份-》移動日志備份文件-》還原日志備份文件-》設置數據庫為讀寫模式 ，整個過程花費時間超過15分鐘
只能滿足要求二，不能滿足要求一，并且一旦遷移過程出錯，回滾時間+遷移時間>要求的停機時間
回滾：一旦15樓的數據庫有數據寫入，要回滾需要完整備份數據庫或分離數據庫然后還原到10樓或附加到10樓的數據庫，回滾時間無法滿足小于10分鐘的要求
 
方案三 AlwaysOn
跟客戶商量溝通之后，最終選定SQL Server的AlwaysOn
從示意圖可以看出，目前的架構需要做如何升級
增加一個成都機房
所有數據庫升級到SQL Server2014 SP2
所有操作系統升級到Windows2012R2
回滾：一旦15樓的數據庫有數據寫入，要回滾可以先kill掉數據庫所有連接，禁用數據庫帳號不讓連接數據庫，等成都從庫同步完數據之后，重新手動故障轉移回去成都機房
整個回滾過程10分鐘之內可以搞定
 
 
 
然后嗶哩吧啦嗶哩吧啦過了一個月，客戶說軟件和硬件環境都已經準備好了，當中數據庫升級過程走起君也有參與在內
升級完畢之后的環境
操作系統：Windows2012R2
數據庫：SQL Server2014 SP2
兩邊機房帶寬：各10M   沒有拉專線
VPN：使用華為防火墻內置的VPN功能
數據庫大小：100G+
AlwaysOn節點數：5個  重慶機房3個  成都機房2個
 
升級之后的示意圖
 
到目前為止，大家可能已經猜到走起君做了這個架構之后要怎麼做了
由于是點對點VPN，所以切換過程涉及拆除VPN和重建VPN的過程
切換過程
（1）主庫切換到成都機房
（2）拆除10樓到成都機房的VPN
（3）10樓所有服務器關機搬到15樓
（4）15樓所有服務器開機
（5）重建15樓到成都的VPN，建好VPN之后，成都機房的主庫和域控會自動與重慶機房的域控和從庫通信，主庫會把差異數據發回重慶，無須人工介入
（6）成都機房主庫切換回去重慶機房15樓
 
 
這里有一個比較嚴重的問題
客戶沒有使用專線，兩邊機房只有10M帶寬！
客戶沒有使用專線，兩邊機房只有10M帶寬！
客戶沒有使用專線，兩邊機房只有10M帶寬！
重要的問題說三遍！
 
這樣一個低成本的架構，沒有專線，帶寬不高，只用硬件防火墻的VPN搭建起來的內網，SQL Server可以做得到嗎？？？
答案是：沒問題，SQL Server完全做得到！！！
 
這里軟件環境需要滿足下面要求
1、操作系統必須是Windows2012R2或以上版本
2、數據庫必須是SQL Server2012或以上版本
 
 
再次用文字描述一下切換過程
第一步：在重慶機房節點kill掉所有數據庫連接并設置程序用數據庫帳號設置為禁用，禁止連接數據庫
第二步：打開AlwaysOn的AG的屬性界面，將成都異地節點改為同步提交模式
第三步：使用腳本查看當前數據庫中各個表的記錄數，腳本地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第四步：打開AlwaysOn的顯示面板，查看成都機房節點數據同步情況，如果已經追上主庫的日志那么實施故障轉移
第五步：手動進行故障轉移
第六步：在成都機房節點查看AlwaysOn的轉移情況
第七步：在成都機房節點使用腳本驗證當前數據庫中各個表的記錄數是否與手動故障轉移之前的記錄數相同，腳本地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第八步：在成都機房節點打開AlwaysOn的AG的屬性界面，將所有的輔助副本都改為異步提交模式
第九步：拆除10樓到成都的VPN
第十步：重慶機房所有數據庫服務器關閉SQL服務然后關機
第十一步：所有服務器搬到15樓并開機
第十二步：重建15樓到成都的VPN
第十三步：在成都機房節點kill掉所有數據庫連接并設置程序用數據庫帳號設置為禁用，禁止連接數據庫
第十四步：在成都機房節點打開AlwaysOn的AG的屬性界面，將原來重慶機房的主副本節點改為同步提交模式
第十五步：使用腳本查看當前數據庫中各個表的記錄數，腳本地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第十六步：打開AlwaysOn的顯示面板，查看重慶機房節點數據同步情況，如果已經追上主庫的日志那么實施故障轉移
第十七步：手動進行故障轉移
第十八步：在重慶機房節點查看AlwaysOn的轉移情況
第十九步：在重慶機房節點使用腳本驗證當前數據庫中各個表的記錄數是否與手動故障轉移之前的記錄數相同，腳本地址：http://www.cnblogs.com/lyhabc/p/3828496.html
第二十步：在重慶機房節點打開AlwaysOn的AG的屬性界面，將成都節點副本改為異步提交模式
 
 
整個過程非常順利，沒有數據丟失，停機時間控制在10分鐘之內
 
 

---

原理
相信不少人都用過SQL Server的AlwaysOn集群，AlwaysOn集群真的是非常方便，隨意切換
數據做了加密和壓縮 ，數據庫塊級別的傳輸
數據自動補償
切換和回切不需要重建集群
操作傻瓜化
數據0丟失
 
重慶機房關機時間段數據自動補償，避免數據丟失
 
 
兩個停機時間點，每個時間點大約5分鐘
時間點1
時間點2
 
最后一個，之所以要使用Windows2012R2操作系統，是因為Windows2012R2引入了動態仲裁機制，也就是說當前WSFC集群只有一個節點的情況下
整個WSFC集群也會不會掛掉
 
利用這個機制，當重慶機房所有服務器關機的情況下，成都機房的數據庫節點依然能working，這個相比Windows2008R2是一個相當大的進步
 
這里有一個注意點
在Windows2008R2時代，因為沒有動態仲裁機制，所以需要將異地節點的投票權去掉，這里有幾個原因
1、當異地節點掛掉之后，整個WSFC集群節點湊不夠基數，導致整個WSFC集群失去仲裁掛掉
2、主庫無故切換到異地節點（設置為手動故障轉移防止這種情況發生）
3、SQL2012異地節點無故變為正在解析狀態（重啟異地節點數據庫服務器的SQL Server服務解決這個問題，現在SQL2014 SP2沒出現過這個問題）
 
 
而到了Windows2012R2時代，有些老司機依然會繼續使用這種做法，把異地節點的投票權去掉，這樣做的話，當前整個WSFC集群沒有一個節點擁有投票的情況下整個WSFC集群就會掛掉，成都機房的AG就會顯示“正在解析”，這是因為當前整個WSFC集群里面沒有一個節點擁有投票權，即使成都這個節點在開機狀態，所以提醒一下大家，如果操作系統是Windows2012R2，不需要把異地節點投票權去掉，因為到目前為止，在上面的三種情況下，第二和第三種情況通過方法可以解決，第一種情況因為Windows2012R2引入了動態仲裁機制也不會發生
 
如上圖，在只有成都節點的情況下，整個WSFC也不會掛掉

---

總結
 
到目前為止，走起君發現身邊使用SQL Server的朋友大多只在本地機房部署AlwaysOn，而沒有部署AlwaysOn異地節點
只在本地機房部署AlwaysOn是不利于應對風險的，做AlwaysOn異地容災其實還有很多好處
 
 
使用場景
機房斷網斷電：之前有一個新聞《脈脈失聯的15個小時》，聯通凈網行動把機房斷網了，如果做了AlwaysOn異地節點那么可以把主庫先切換到別的機房，應用也一并切換過去
那么就可以規避這種風險了
http://mt.sohu.com/20160730/n461773714.shtml
 
BI：BI抽取大量數據會影響線上的網絡穩定性，部署AlwaysOn異地節點，BI從異地節點抽取業務數據，可以減少對業務的影響
 
數據庫備份集中保存：因為線上服務器的磁盤容量一般都很有限，一般只保留幾天或者一個星期的數據庫備份，部署AlwaysOn異地，對異地節點數據庫做完整備份
然后拷貝到備份服務器或磁帶庫，這樣就可以保存比較長時間的數據庫備份，即使開發要找回半年甚至一年之前的那個數據也是可以的
 
SQL Review：代碼審核，收集數據庫性能數據，排查性能問題，盡可能減少對主庫的影響
 
最后這次項目的整個切換過程還有很多細節，就不寫在文章里了，有興趣的朋友可以發站短跟我交流^_^
 
 
參考文章
http://www.tech-coffee.net/understand-failover-cluster-quorum/
http://windowsitpro.com/windows-server-2012/dynamic-quorum-windows-server-2012
 
附上AlwaysOn搭建教程
第一篇
http://www.cnblogs.com/lyhabc/p/4678330.html
第二篇
http://www.cnblogs.com/lyhabc/p/4682028.html
第三篇
http://www.cnblogs.com/lyhabc/p/4682986.html
第四篇
http://www.cnblogs.com/lyhabc/p/6136227.html
 
如有不對的地方，歡迎大家拍磚o(∩_∩)o 
本文版權歸作者所有，未經作者同意不得轉載。

文章出處
從0開始搭建SQL Server AlwaysOn 第四篇（配置異地機房節點）
 
第一篇
http://www.cnblogs.com/lyhabc/p/4678330.html
第二篇
http://www.cnblogs.com/lyhabc/p/4682028.html
第三篇
http://www.cnblogs.com/lyhabc/p/4682986.html
第四篇
http://www.cnblogs.com/lyhabc/p/6136227.html
 
這一篇是從0開始搭建SQL Server AlwaysOn 的第四篇，這一篇開始搭建異地機房節點
 
注意點1
注意異地節點最好至少有2個AG節點，否則在本地節點進行手動故障轉移的時候會出現仲裁警告，提示WSFC集群有脫機危險
在異地節點只有一個的情況下，雖然Windows2012R2有動態仲裁機制，但是，當本地節點非優雅宕機的情況下，整個WSFC集群有可能得不到任何票數
也就是異地節點也得不到票數而導致整個WSFC集群脫機！！
 
注意點2
當進行手動故障轉移的時候，更新DNS緩存需要10分鐘，所以當進行手動故障轉移之后，用偵聽器ip連接SQL Server會很慢，這是因為還在更新DNS緩存
 
 

---

步驟
這一篇依然使用step by step的方式介紹怎麼搭建AlwaysOn異地機房節點
 
新加異地機房節點機器名：
 
1、在異地節點上安裝故障轉移集群
 
 
2、在本地機房節點機器上打開故障轉移集群管理器，添加一個節點
 
3、驗證配置
 
 
4、解決新加節點OU不同問題，只需修改組織單位ou，不需要修改站點site，因為如果本地機房和異地機房的域設置了site，在驗證配置的時候會警告，當然可以忽略也可以修正
因為只是警告已而，忽略也無所謂
 
 
5、添加節點成功
 
6、在新節點上安裝好SQL Server并優化SQL Server，這里忽略安裝和優化步驟
 
7、把異地機房新節點添加到alwayson可用性組里，打開alwayson的可用性屬性界面，可用性組名稱為：AGWMSJXC
 
 
可以看到添加了異地機房節點之后，這個異地機房節點還沒有聯接到可用性組，也就是當前可用性組還沒識別到這個異地機房節點
 
8、對偵聽器添加另一個子網的VIP，這一步，如果可用性組沒有啟用可用性組偵聽器那么這一步可以忽略
如果可用性組啟用了偵聽器，那么需要分兩種情況
1、異地節點的網段跟本地機房是一樣的，比如都是192.168.1.x ，那么這一步也不需要做
2、異地節點的網段跟本地機房是不一樣的，也就是跨子網，比如本地機房是192.168.1.x，異地機房是192.168.10.x，那么這一步需要做
現在偵聽器IP有兩個，一個是本地機房網段的IP，一個是異地機房網段的IP
 
添加了新的偵聽器vip之后，故障轉移集群管理器里會自動將這個偵聽器vip資源脫機
 
 
 
9、新建一個測試可用性組，主要用來打通/開啟本地節點和異地節點的5022端口
 
建好之后，在原AG刷新一下會看到異地節點JXCA-WMS08已經自動聯接到可用性組AGWMSJXC
 
 
10、對數據庫進行備份還原到異地節點JXCA-WMS08，在異地節點JXCA-WMS08上進行操作，將數據庫逐個點擊聯接到可用性組
 
11、異地節點添加完成
 
 
12、手動故障轉移主副本到異地節點
注意當只有一個異地節點的時候，正在驗證WSFC仲裁投票配置那一欄會出現警告！
故障轉移之后會發現異地節點的偵聽器ip聯機，本地節點的偵聽器ip脫機
 
13、在異地節點上使用異地節點偵聽器ip連接SQL Server，并寫入測試數據
 
14、把主副本手動故障轉移回來本地節點
 
15、用本地節點偵聽器ip連接SQL Server，發現剛才對異地節點偵聽器ip的數據寫入都已經同步過來本地機房節點
 
 
16、添加WSFC集群IP地址資源的異地機房IP，在WSFC管理器里選中群集核心資源下面的服務器名稱，右鍵-》屬性
添加一個異地機房的WSFC的vip：192.168.7.130
添加成功之后vip會顯示脫機這是因為當前WSFC主節點不在異地機房的節點上，而是本地機房的節點上
 
 
17、把WSFC主節點轉移到異地機房的某個節點，然后把本地所有節點都關機
 
這時候把本地機房的所有節點關機
 
現在用異地機房節點的WSFC的vip連接WSFC集群
可以發現WSFC的主節點已經轉移到WIN-BDKSOOLDV18這個異地節點上了，而且群集資源還是聯機狀態
 
 
提示：實際上第16步不是必須的，你可以不添加WSFC的異地子網的vip，但是當本地機房所有節點關機之后
你就不能用本地的vip：192.168.6.60來連接WSFC集群，也就無法管理WSFC集群
 
 
附上結構圖
兩個網段，所以會有兩個偵聽器IP，但是同一個時刻只有一個偵聽器IP是聯機狀態，在WSFC集群管理器里查看
主站點：192.168.6x
DR站點：192.168.7.x
故障轉移到DR站點之后
 
 
參考文章：
http://blog.itpub.net/29371470/viewspace-2087672
http://www.tech-coffee.net/understand-failover-cluster-quorum/
 
如有不對的地方，歡迎大家拍磚o(∩_∩)o 
本文版權歸作者所有，未經作者同意不得轉載。