SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 產品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 伺服器集群简单化
  • 成功案例
    • 台灣成功案例
  • 聯繫我們
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

使用Fusion-io最大化Linux群集的複制性能

27 11 月, 2018 by Jason Aw Leave a Comment

使用Fusion-io最大化Linux群集的複制性能

使用Fusion-io最大化Linux群集的複制性能的技巧

當大多數人考慮設置群集時,它通常涉及兩個或更多服務器,以及SAN或其他類型的共享存儲。SAN的設置和維護通常非常昂貴且複雜。此外,它們在技術上代表了集群架構中潛在的單點故障(SPOF)。如今,越來越多的人開始使用Fusion-io這樣的公司,以及他們閃電般快速的ioDrives,來加速關鍵應用。  這些存儲設備位於服務器內(即不是“共享磁盤”)。 因此,它不能用作具有許多傳統群集解決方案的群集磁盤。幸運的是,有一些方法可以最大化使用Fusion-io進行Linux群集的複制性能。 允許您在不涉及共享存儲時形成故障轉移群集的解決方案 – 即“無共享”群集。

傳統集群 使用Fusion-io - 傳統集群最大化Linux集群的複制性能  “無共享”集群使用Fusion-io - 無共享群集最大化Linux群集的複制性能

在將數據複製作為群集配置的一部分時,充足的帶寬至關重要,這樣才能在網絡上複製數據,就像寫入磁盤一樣快。  以下是調優技巧,可讓您在涉及高速存儲時充分利用“無共享”群集配置:

網絡

  • 使用10Gbps網卡:Fusion-io(或OCZ,LSI等其他類似產品)的基於閃存的存儲設備能夠以MB /秒或更高的百萬分之一(750)的速度寫入數據。  1Gbps網卡只能推動理論最大值~125 MB /秒,因此任何利用ioDrive潛力的人都可以比通過1 Gbps網絡連接推送更快地寫入數據。  為確保服務器之間有足夠的帶寬以促進實時數據複製,應始終使用10 Gbps NIC來承載複製流量
  • 啟用巨型幀:假設您的網卡和交換機支持它,啟用巨型幀可以大大提高網絡吞吐量,同時減少CPU週期。  要啟用巨型幀,請執行以下配置(例如來自RedHat / CentOS / OEL linux服務器)
    • ifconfig <interface_name> mtu 9000
    • 編輯/ etc / sysconfig / network-scripts / ifcfg- <interface_name>文件並添加“MTU = 9000”,以便在重新啟動後更改仍然存在
    • 要驗證端到端巨型幀操作,請運行以下命令:ping -s 8900 -M do <IP-of-other-server>
  • 更改NIC的傳輸隊列長度:
    • / sbin / ifconfig <interface_name> txqueuelen 10000
    • 將其添加到/etc/rc.local以保留重新啟動後的設置

TCP / IP調整

  • 更改NIC的netdev_max_backlog:
    • 在/etc/sysctl.conf中設置“net.core.netdev_max_backlog = 100000”
  • 已顯示可提高複制性能的其他TCP / IP調整:
    • 注意:這些是示例值,有些可能需要根據您的硬件配置進行調整
    • 編輯/etc/sysctl.conf並添加以下參數:
      • net.core.rmem_default = 16777216
      • net.core.wmem_default = 16777216
      • net.core.rmem_max = 16777216
      • net.core.wmem_max = 16777216
      • net.ipv4.tcp_rmem = 4096 87380 16777216
      • net.ipv4.tcp_wmem = 4096 65536 16777216
      • net.ipv4.tcp_timestamps = 0
      • net.ipv4.tcp_sack = 0
      • net.core.optmem_max = 16777216
      • net.ipv4.tcp_congestion_control = HTCP

調整

通常,您還需要對群集配置進行調整,這將根據您決定實施的群集和復制技術而有所不同。  在這個例子中,我使用的是SIOS Technologies的SteelEye Protection Suite for Linux(又名SPS,又名LifeKeeper)。 它允許用戶利用幾乎任何後端存儲類型形成故障轉移群集:光纖通道SAN,iSCSI,NAS,或者與本文最相關的本地磁盤,需要在群集節點之間實時同步/複製。  SPS for Linux包括集成的塊級數據複製功能,這使得在沒有共享存儲時很容易設置集群。

建議

為了最大化使用Fusion-io的Linux群集的複制性能,讓我們試試這個。SteelEye Protection Suite(SPS)for Linux配置建議:

  • 分配位於Fusion-io驅動器上的小(~100 MB)磁盤分區以放置位圖文件。  在此分區上創建一個文件系統並將其掛載,例如,在/ bitmap:
    • #mount | grep /位圖
    • / dev / fioa1 on / bitmap type ext3(rw)
  • 在創建鏡像之前,請在/ etc / default / LifeKeeper中調整以下參數
    • 插入:LKDR_CHUNK_SIZE = 4096
      • 默認值為64
    • 編輯:LKDR_SPEED_LIMIT = 1500000
      • (默認值為50000)
      • LKDR_SPEED_LIMIT指定重新同步將採用的最大帶寬 – 應設置為足夠高以允許重新同步以盡可能最大的速度運行
    • 編輯:LKDR_SPEED_LIMIT_MIN = 200000
      • (默認值為20000)
      • LKDR_SPEED_LIMIT_MIN指定當同時進行其他I / O時允許重新同步的速度 – 根據經驗,這應該設置為驅動器的最大寫入吞吐量的一半或更少,以避免挨餓重新同步發生時,正常的I / O活動

從這裡開始,像往常一樣創建鏡像並配置群集。有興趣通過Fusion-io最大化Linux群集的複制性能,請參閱SIOS可以提供的其他內容。經LinuxClustering許可轉載

Filed Under: Datakeeper, 伺服器集群简单化 Tagged With: Fusion-io的

在Google域名之間移動Google表單

23 11 月, 2018 by Jason Aw Leave a Comment

在Google域名之間移動Google表單

在Google域名之間移動Google表單

如果您和我一樣,您可能會定期使用一些不同的Google帳戶。最近,我在Google域之間移動Google表單方面需要幫助。我花了相當多的時間創建Google表單。只是意識到我在使用我的個人帳戶而不是我的工作帳戶登錄時這樣做了。我真的不想重做我做過的工作。我嘗試在線搜索答案,但沒有具體的解決方案來解決我的情況。這並不難。我想我會把它寫下來以防萬一發生在你身上。我只是嘗試了幾件事,偶然發現了這個問題。我們假設這是一個沒有數據的新表單。在Google Domains中移動Google表單時,您只需執行以下操作:

  1. 在表單上添加您的第二個Google帳戶作為協作者
  2. 登錄您的第二個Google帳戶,打開表單並填寫表單的“複製件”

在Google域名之間移動Google表單 而已!現在,您在第二個Google帳戶中獲得了該表單的副本。當然,如果您已經在第一個表單上收集了一些數據,則需要復制該表。 將它放在您的第二個Google帳戶中,並將表單附加到該數據副本。請務必刪除舊表單,以免意外使用舊表單。閱讀諸如在Google Domains之間移動Google表單等提示,並獲得Clusteringformeremortals的許可

Filed Under: 伺服器集群简单化

使用SIOS DataKeeper接收電子郵件警報

19 11 月, 2018 by Jason Aw Leave a Comment

使用SIOS Datakeeper接收電子郵件警報

使用SIOS DataKeeper接收電子郵件警報

在過去的幾周里,我寫了一個由3部分組成的系列文章,介紹如何根據Perfmon計數器,系統事件日誌條目和特定的Windows服務啟動或停止事件來配置電子郵件警報。這些指南與任何環境相關。我的所有例子都是為了監控SIOS DataKeeper。此外,它還有一些特定的客戶請求,包括監控SIOS DataKeeper服務,以及在RPO超過5秒時收到警報。我還包括監視您想要了解的基本DataKeeper事件。此視頻顯示了一些此警報。

有興趣了解有關SIOS DataKeeper的更多信息,請閱讀我們的SIOS成功案例經Clusteringformeremortals許可轉載

Filed Under: 伺服器集群简单化

特定Windows服務啟動或停止時觸發電子郵件警報

18 11 月, 2018 by Jason Aw Leave a Comment

如何在Windows Server 2016上啟動或停止特定Windows服務時觸發電子郵件警報

循序漸進:如何在Windows Server 2016上啟動或停止特定Windows服務時觸發電子郵件警報

與我上一篇文章的不同之處在於,我向您展示瞭如何根據Windows事件日誌中記錄的特定Windows EventID發送電子郵件警報,這次我將分享如何在特定Windows服務啟動或停止時觸發電子郵件警報。它適用於大多數活動。雖然請注意,如果您希望在特定Windows服務啟動或停止時收到通知,這並不理想。當Windows服務啟動或停止時,Windows系統日誌中會記錄源“服務控制管理器”中的EventID 7036。現在,我們可以設置一個觸發器,以便在記錄EventID時發送電子郵件,就像我在上一篇文章中所描述的那樣。 但是,您可能不希望在每個Windows服務啟動或停止時收到電子郵件。為了更具體一點,我們必須在設置觸發器時編輯與Windows事件過濾器關聯的XML數據。這是為了更深入地了解事件屬性並對EventData進行過濾,該事件僅在您在Windows事件的“詳細信息”選項卡上查看XML視圖時顯示。這項工作在Windows Server 2016上得到了驗證,但我懷疑它也可以在Windows Server 2012 R2和Windows Server 2019上運行。如果您在任何其他平台上工作,請發表評論並告知我們您是否需要更改任何內容。

第1步 – 編寫Powershell腳本

您需要做的第一件事是編寫一個Powershell腳本,在運行時可以發送電子郵件。您需要該電子郵件才能在特定Windows服務啟動或停止時觸發電子郵件警報。有很多方法可以完成這項任務。我即將向您展示只是一種方式,但您可以隨意嘗試並使用適合您環境的方法。在我的實驗室中,我沒有運行自己的SMTP服務器,因此我必須編寫一個可以利用我的Gmail帳戶的腳本。您將在我的Powershell腳本中看到對SMTP服務器進行身份驗證的電子郵件帳戶的密碼是純文本格式。如果您擔心某人可能有權訪問您的腳本並發現您的密碼,那麼您將需要加密您的憑據。Gmail需要和SSL連接,因此您的密碼應該是安全的,就像任何其他電子郵件客戶端一樣。下面是一個Powershell腳本示例,當與Task Scheduler結合使用時,它會在Windows事件日誌中記錄任何指定的事件時自動發送電子郵件警報。在我的環境中,我將此腳本保存到C: Alerts ServiceAlert.ps1

$ filter =“* [System [EventID = 7036] and EventData [Data ='SIOS DataKeeper']]”
$ A = Get-WinEvent -LogName系統-MaxEvents 1 -FilterXPath $ filter
$ Message = $ A.Message
$ EventID = $ A.Id
$ MachineName = $ A.MachineName
$ Source = $ A.ProviderName


$ EmailFrom =“sios@medfordband.com”
$ EmailTo =“sios@medfordband.com”
$ Subject =“來自$ MachineName的警報”
$ Body =“EventID:$ EventID`nSource:$ Source`nMachineName:$ MachineName`n $ Message”
$ SMTPServer =“smtp.gmail.com”
$ SMTPClient = New-Object Net.Mail.SmtpClient($ SmtpServer,587)
$ SMTPClient.EnableSsl = $ true
$ SMTPClient.Credentials = New-Object System.Net.NetworkCredential(“sios@medfordband.com”,
 “MySMTPP @ 55w0rd”);
$ SMTPClient.Send($ EmailFrom,$ EmailTo,$ Subject,$ Body)

從Powershell腳本生成的電子郵件示例如下所示。服務警報電郵 您可能已註意到此Powershell腳本使用Get-WinEvent cmdlet根據LogName,EventID和EventDataspecified獲取最新的事件日誌條目。然後它解析該事件並將EventID,Source,MachineName和Message分配給將用於撰寫電子郵件的變量。您將看到指定的LogName,EventID和EventData與您在步驟2中設置計劃任務時指定的內容相同。雖然EventID,LogName可能對您來說很熟悉,但EventData可能並不那麼熟悉。要查看與特定事件關聯的EventData,您需要在事件查看器中打開事件,查看“詳細信息”選項卡,然後選擇“XML視圖”。從XML視圖中,您可以看到事件中包含的所有數據。在XML的底部附近,您將看到一個名為<EventData>的數據數組。在那裡,您將找到存儲為參數的其他事件數據。如下所示,在“param1”中,我們將找到停止或啟動的服務名稱。事件數據

第2步 – 設置計劃任務

在任務計劃程序中創建一個任務,如以下屏幕截圖所示。

  1. 創建任創建任務務確保將任務設置為“運行”,無論用戶是否已登錄。服務 - 一般
  2.  在“觸發器”選項卡上,選擇“新建”以創建將啟動“在事件上”任務的觸發器。在我的示例中,我將創建一個事件,觸發任何時候DataKeeper(extmirr)將重要事件記錄到系統日誌。創建任務3 創建一個自定義事件和新事件過濾器,如下所示..創建任務 - 觸發器.對於我的觸發器,您可以開始設置一個監視7036的觸發器,正如我在上一篇文章中所描述的那樣。但是,過濾器GUI界面不允許我們指定存儲在EventData的Param1中的服務名稱,如前所述。為了監控我們感興趣的特定服務,我們需要直接編輯XML,如下所示。服務 - XML 如果您只是直接跳到追逐,請隨意複製我的XML,並將“SIOS DataKeeper”替換為存儲在您要監控的事件的param1中的事件數據。
    <QueryList>
    <Query Id =“0”Path =“System”>
    <Select Path =“System”> * [System [(Level = 4或Level = 0)和(EventID = 7036)]] 
    和* [EventData [Data [1] ='SIOS DataKeeper']] </ Select>
    </查詢>
    </ QueryList>
  3. 配置事件觸發器後,您將需要配置事件運行時發生的操作。在我們的例子中,我們將運行我們在步驟1中創建的Powershell腳本。行動 - 2服務 - 任務
  4. 默認的Condition參數應該足夠了。條件 - 1
  5. 最後,在“設置”選項卡上,確保允許按需運行任務,並在任務已在運行時“排隊新實例”。

    2018-10-28_00-17-27

步驟3(如有必要) – 修復Microsoft -Windows – Distributedcom事件ID:10016錯誤

理論上,如果您正確地執行了所有操作,則只要您正在監視的某個事件記錄在事件日誌中,您就應該立即開始接收電子郵件。  但是,我在我的一台服務器上遇到了一個奇怪的權限問題,我必須在一切工作之前解決這個問題。我不確定你是否會遇到這個問題,但以防這裡是修復。在我的情況下,當我手動觸發事件,或者我直接運行Powershell腳本時,一切都按預期工作,我收到了一封電子郵件。但是,如果正在監視的某個EventID被記錄到事件日誌中,則不會導致發送電子郵件。我唯一的線索是每當我期望任務觸發器檢測到記錄的事件時,我的系統事件日誌中記錄的事件ID:10016。

日誌名稱:系統
來源:Microsoft-Windows-DistributedCOM
日期:10/27/2018 5:59:47 PM
事件ID:10016
任務類別:無
等級:錯誤
關鍵詞:經典
用戶:DATAKEEPER  dave
電腦:sql1.datakeeper.local
描述:
特定於應用程序的權限設置不授予“本地激活”權限 
對於具有CLSID的COM Server應用程序 
{D63B10C5-BB46-4990-A94F-E40B9D520160}
和APPID 
{9CA88EE3-ACB7-47C8-AFC4-AB702511C276}
給用戶DATAKEEPER  dave SID(S-1-5-21-25339xxxxx-208xxx580-6xxx06984-500)來自 
地址LocalHost(使用LRPC) 
在應用程序容器中運行不可用SID(不可用)。
可以使用組件服務管理工具修改此安全權限。

此錯誤的許多Google搜索結果都表明該錯誤是良性的,並包含有關如何抑制錯誤而非修復錯誤的說明。但是,我非常確定此錯誤是導致我當前無法從受監視的事件日誌條目觸發的計劃事件發送電子郵件警報的原因。我需要解決它。經過多次搜索,我偶然發現了這個新聞組的討論。  Marc Whittlesey的回應使我指出了正確的方向。這是他寫的……

在轉到組件服務中的DCOM配置之前,您必須設置2個註冊表項:CLSID密鑰和APPID密鑰。

我建議你按照一些步驟解決問題:

1。 按Windows + R鍵並鍵入regedit,然後按Enter鍵。2。 轉到HKEY_Classes_Root CLSID * CLSID *。3。 右鍵單擊它然後選擇權限。4。 單擊“高級”並將所有者更改為管理員。同時單擊將顯示在所有者行下方的框。5。 適用完全控制。6。 關閉選項卡,然後轉到HKEY_LocalMachine Software Classes AppID * APPID *。7。 右鍵單擊它然後選擇權限。8。 單擊“高級”並將所有者更改為管理員。9。 單擊將顯示在所有者行下方的框。10。 單擊“應用”並向管理員授予完全控制權。11。 關閉所有選項卡,然後轉到管理工具。12。 開放組件服務。13。 單擊“計算機”,單擊“我的電腦”,然後單擊“DCOM”。14。 查找錯誤查看器上顯示的相應服務。15。 右鍵單擊它,然後單擊屬性。16。 單擊安全選項卡,然後單擊添加用戶,添加系統,然後應用 17。 勾選激活本地框。因此,請在此處使用相關密鑰,DCOM配置應該可以訪問灰色區域:CLSID {D63B10C5-BB46-4990-A94F-E40B9D520160} APPID {9CA88EE3-ACB7-47C8-AFC4-AB702511C276}

我幾乎可以逐字逐句地遵循步驟1-15。然而,當我到達第16步時,我真的無法確切地說出他想要我做什麼。起初我將DATAKEEPER dave用戶帳戶完全控制授予RuntimeBroker。但這並沒有解決問題。最後我只是在所有三個權限上選擇了“使用默認值”並修復了問題。RuntimeBroker 我不確定這是怎麼發生的,為什麼會發生這種情況,但我想我最好把它全部寫下去以防它再次發生,因為我花了一段時間來弄清楚它。

步驟4-自動部署

如果需要在多個系統上啟用相同的警報,只需將任務導出到XML文件並將其導入其他系統即可。導出[/ caption] [captio特定Windows服務啟動或停止時的電子郵件警報n id =“attachment_2346”align =“alignnone”width =“391”]導入[/ caption]甚至更好,在文件共享中提供XML文件後,通過Powershell腳本自動執行構建過程中的導入,如以下示例所示。

PS C:> Register-ScheduledTask -Xml(get-content'\ myfileshare  tasks  DataKeeperAlerts.xml' 
| out-string)-TaskName“DataKeeper Service Alerts”-User datakeeper  dave 
-Password MyDomainP @ 55W0rd -Force

最後,特定Windows服務啟動或停止時的電子郵件警報

希望我提供的內容能為您提供開始接收警報通知電子郵件所需的一切,無論您使用哪種Windows服務讓您夜不能寐。以上是關於配置電子郵件警報的系列文章。在本系列中,我介紹了基於Perfmon計數器,事件日誌條目以及本文Windows服務啟動和停止事件的配置警報。當然,您可以擴展這些文章中描述的Powershell腳本,而不僅僅是發送電子郵件。許多警報或意外服務中斷通常需要一些補救措施。為什麼不編寫恢復步驟的腳本,讓觸發的任務為您解決問題?我個人建議您投資SCOM,SolarWinds或其他一些企業管理系統,但如果這不在您工作的卡片中,那麼這些文章可以幫助您。要了解有關特定Windows服務啟動或停止時的電子郵件警報的更多提示,請與我們聯繫轉發,並獲得Clusteringformeremortals.com的許可

Filed Under: 伺服器集群简单化 Tagged With: 特定Windows服務啟動或停止時的電子郵件警報

將SQL Server 2008和2008 R2群集移至Azure以獲得擴展支持

16 11 月, 2018 by Jason Aw Leave a Comment

將SQL Server 2008和2008 R2群集移至Azure以獲得擴展支持

將SQL Server 2008和2008 R2群集移至Azure以獲得擴展支持

今年早些時候,如果將SQL Server 2008和2008 R2群集遷移到Azure,Microsoft將宣布擴展支持。 有關所有詳細信息,請查看https://www.microsoft.com/en-us/sql-server/sql-server-2008。 如果您選擇不搬家,您的延期支持將於2019年7月9日結束。將SQL Server 2008和2008 R2群集移至Azure以獲得擴展支持 如果您仍在運行SQL Server 2008 R2,可能是因為您從未升級過您的應用程序。因此不支持更新版本的SQL。或許,你決定不修復沒有破壞的東西。無論這些原因如何,如果您遷移到Azure,您剛剛為自己購買了三年的支持。現在,使用Azure Site Recovery將工作負載遷移到Azure是一個很好的文檔化過程。對於SQL Server的獨立實例,該過程應該是非常無縫的。但是那些SQL Server的集群實例呢?當你搬到Azure時,你肯定不想放棄可用性。Azure的一部分優點是它們擁有您夢寐以求的基礎設施。但是,用戶有責任配置其應用程序以充分利用基礎結構,以確保您的部署具有高可用性。對於SQL Server 2008和2008 R2,高可用性通常意味著Windows Server 2008 R2或Windows Server 2012 R2上的SQL Server故障轉移群集。如果您是Azure的新手,您將很快發現沒有支持共享存儲群集的本機選項。相反,您需要查看SANLess集群解決方案,例如SIOS DataKeeper。Microsoft在其文檔中列出了SIOS DataKeeper作為SQL Server故障轉移群集的HA解決方案。

將SQL Server 2008和2008 R2群集移至Azure以獲得擴展支持
https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-sql-high-availability-dr

入門

讓我們開始將SQL Server 2008和2008 R2集群遷移到Azure以獲得擴展支持。以下是您需要採取的高級步驟。

  • 使用DataKeeper卷資源替換現有內部部署SQL Server群集中的物理磁盤資源。如果使用MSDTC,請對MSDTC資源執行相同操作。
  • 刪除您的磁盤見證並將其替換為文件共享見證。
  • 使用Azure Site Recovery將群集節點複製到Azure中,確保每個複制節點位於Azure中的不同故障域或不同可用區中
  • 在Azure中恢復複製群集節點
  • 將文件共享見證替換為Azure中託管的文件共享
  • 在Azure中配置內部負載均衡器以進行客戶端重定向。這包括在本地節點上運行Powershell腳本以更新SQL Cluster IP資源以偵聽ILB探測
  • 假設在此遷移過程中更改了SQL Server群集實例的IP地址和子網,您還需要對群集IP地址和DataKeeper作業端點進行一些清理以反映新的IP地址

我知道我遺漏了很多細節。但是,如果您發現自己處於不得不將SQL Server升級到Azure或任何云計算的位置,我很樂意與您聯繫以回答您可能遇到的任何問題。請記住,相同的步驟適用於您計劃遷移到Azure的任何SQL版本。如果您需要將SQL Server 2008和2008 R2 Clusters移至Azure,請與我們聯繫。經Clusteringformeremortals.com許可轉載

Filed Under: 伺服器集群简单化 Tagged With: 2008 R2集群, SQL Server 2008, 將sql server 2008和2008 r2集群移動到azure

  • « Previous Page
  • 1
  • …
  • 69
  • 70
  • 71
  • 72
  • 73
  • …
  • 98
  • Next Page »

最近的帖子

  • 在 Nutanix 環境中選擇高可用性解決方案的 10 個注意事項
  • 我的伺服器是一次性的嗎?高可用性軟體如何適應雲端最佳實踐
  • 災難頻傳世界的資料復原策略
  • DataKeeper 與棒球:災難復原的策略性舉措
  • SQL Server 停機風險預算

最熱門的帖子

加入我們的郵件列表

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in