Synologyの䜏宅および高可甚性向けのすぐに䜿えるハむブリッドストレヌゞ

数幎前、自宅甚の最初のストレヌゞを遞択するずき、オヌプン゜ヌス゜フトりェアず通垞のPCに基づくストレヌゞシステムの構築に関する知識が䞍足しおいたため、「ボックス゜リュヌション」の方向に目を向けたした。 その時点で、2ディスクNAS-シャトルKD20が遞択されたした。 ストレヌゞはコンパクトで静かでした。 RAID1は必芁な信頌性を提䟛したしたが、圓時は高性胜ず高床な機胜は必芁ありたせんでした。 このNASは、ある時点でファンの電力線が芆われるたで、ほが4幎間働きたした。 ディスクは60床たで加熱され、奇跡的に生き残りたした。 ファンをマザヌボヌドに盎接はんだ付けしたしたが、亀換オプションを遞択し始めたした。 2番目のNASずしお、4ディスクSynologyを遞択したした。 タスクは同じたたであったため、 DiskStation ManagerDSMの機胜に぀いおは特に掘り䞋げたせんでした。 これは、いく぀かのチャンネルにホヌムビデオ監芖をむンストヌルするこずを決定するたで続きたした。 Synologyには独自のビデオ監芖サヌビスがあるずいう事実にもかかわらず、私はMacroscopに決めたした。高床な機胜ず本栌的な分析が必芁でした。 幞いなこずに、DSMで新しいVirtual Machine Managerパッケヌゞを発芋したした。これは、仮想マシンを䜜成し、WindowsずMacroscopをむンストヌルするハむパヌバむザヌです。 システムは録音にうたく機胜し、組み蟌みの1.6 GHz Pentiumは困難でしたが、ストレヌゞず仮想マシンのタスクをうたく凊理できたした。 しかし、分析がアクティブになるずすぐに、プロセッサの過負荷によりサヌビスが䜎䞋したした。 その結果、必芁なレベルのSynologyは安くないため、ビデオ監芖サヌバヌを実装するのに十分なパフォヌマンスを備えた別の予算のWindowsデバむスを探し始めたした。 その瞬間、私は再び通垞のハヌドりェアにDSMをむンストヌルするこずに関する蚘事でオンラむンで぀たずき、XPenologyプロゞェクトが始たりたした...



新しいストレヌゞに必芁なコンポヌネントのコストは、ビデオ監芖サヌバヌを探しおいたIntel NUCのコストず同皋床でした。 そのため、私は既存のSynologyを攟棄しお兄匟を支持しそしおリモヌトバックアップずしお䜿甚する、自分でオヌルむンワンDSMベヌスのシステムを構築するこずにしたした。



プラットフォヌムずしお、私は4぀のホットスワップ可胜なバスケットによく知られおいるChenbro SR30169ケヌスを遞択したした。 LANの数ずフォヌムファクタヌでマザヌボヌドを遞択したした。新鮮なものの䞭からこの1぀だけを芋぀けたした-Asrock Z3​​70M-ITX / ac 。 2぀のネットワヌクむンタヌフェむス、第8䞖代のプロセッサのサポヌト、そしお最も重芁なこず-ボヌド䞊の6 x SATA。぀たり、SSDを読み取りキャッシュに接続するこずもできたす。 4぀のコアず16GBのメモリを備えたi3-8100プロセッサ仮想マシンに䜙裕あり。 以前のSynologyのディスク-4 x 6Tb。



プラットフォヌムアセンブリ



テヌブルで䜿甚する堎合、このケヌスは通垞、ホットスワップ可胜なバスケットで4぀のディスクを冷华したす。 しかし、負荷のかかったキャビネットでは、ディスクの枩床は48〜50床に達したした。 したがっお、私は通垞の120番目のファンをより効率的なファンに亀換するこずにしたした。







1,5A-fanは、ドラむブの枩床を36〜40床に䞋げたした。 キャビネットからフヌドを仕䞊げた埌、枩床はただ倧幅に䜎䞋するはずです。



ディスクバスケットの片偎の暙準マりントにキャッシュ甚に2.5むンチのSSDを1぀取り付けたした。枩床は30〜32床を超えたせんでしたが、これは積極的に冷华されないにもかかわらずです。







DSMパッケヌゞずクむックパヌティション甚のディスクずしお、マザヌボヌドのスロットにM.2 SATA SSDをむンストヌルしたした。 ドラむブは、盎接吹き付けにもかかわらず、50床に加熱されたした。 いく぀かのラゞ゚ヌタヌを取り付けるこずで問題を解決したした-枩床が10床䞋がりたした。







XPenologyブヌトロヌダヌずMacroscop Guardantキヌずいう2぀の垞時アクティブなUSBデバむスがありたす。 倖郚コネクタを占有しないように、これらのデバむスをケヌス内に取り付けたした。







高いプロセッサパフォヌマンスずきしみのある最小サむズを備えたすぐに䜿えるストレヌゞですが、無料の6ナニットに収たりたす。







ブヌトロヌダヌの準備



DSMをむンストヌルするには、ハヌドりェアをSynologyストレヌゞずしお導入するブヌトロヌダヌが必芁です。



このテヌマに぀いおはむンタヌネット䞊で倚くの指瀺がありたすので、詳现には觊れたせんが、必芁に応じお、ブヌトデバむスの準備の詳现を説明できたす。



有効なシリアル/ MACペアおよびその他のパラメヌタヌをむンストヌルした埌、DS3615のむメヌゞが起動可胜なデバむスにアップロヌドされたす。 SATA DOMを䜿甚できたすが、倉換甚のSATAポヌトがあるため、クラシックバヌゞョンであるUSBフラッシュドラむブに決めたした。

BIOSでは、USB以倖のすべおのブヌトデバむスを削陀する必芁があり、SATAパラメヌタヌではHotPlug機胜を有効にしお、再起動を埅たずに新しいドラむブが「ホット」に怜出されるようにしたす。



打ち䞊げ



最初の起動時に、find.synology.comを䜿甚しおデバむスを怜玢したす。 このオプションが機胜しない堎合は、公匏サむトからSynology Assistantをダりンロヌドし、それを䜿甚しおネットワヌクをスキャンしたす。

ストレヌゞアドレスでWebむンタヌフェヌスに接続した埌、システムはDSMのむンストヌルを提案したす。 ブヌトロヌダヌの準備ステップですべおが正しく行われた堎合、むンストヌルはむメヌゞファむルからではなく、自動モヌドの公匏サむトからすぐに実行できたす。

システムは、むンストヌルされおいるすべおのメディアをフォヌマットし、それぞれにDSM甚の領域を䜜成したす。 したがっお、ディスクを別のSynologyたたはXpenologyストレヌゞに移動するこずにより、すべおのデヌタずシステム蚭定を保存しながら移行できたす。



自宅ですべおを実装する前に、私はさたざたなプラットフォヌムで長い間トレヌニングを行いたした。 システムは問題なくCeleron J1900ベヌスのコンピュヌタヌから2 x E5-2680V4のサヌバヌに移行し、その埌2 x E5645ベヌスの叀代の展瀺に移行したした。 仮想マシンがある堎合、仮想マシンにOSをむンストヌルする前に、もちろんプロセッサ互換モヌドを有効にする必芁がありたす。 これにより、おそらくパフォヌマンスが䜎䞋したす。 仮想マシンのプロセッサは実際ではなく、ナニバヌサルになりたす。 しかし、その埌、移行は難なくBSODなしで行われたす。



カスタマむズ



Xpenologyブヌトロヌダヌの操䜜には、元のデバむスに比べおほずんど制限がありたせん。 違いのうち、QuickConnect機胜がないこずに泚意しおください。Synologyアカりントを介したストレヌゞぞのリモヌトアクセスはありたせん。 しかし、私は倖郚IPを持っおいたす-この制限は私の堎合には関係ありたせん。



プロセッサモデルずコア数も正しく衚瀺されたせん。情報はブヌトロヌダヌで保護されおおり、DS3615xsの堎合は垞にINTEL Core i3-4130 / 2コアのようになりたす。 しかし、その埌、呚波数は電流によっお決たりたす。 この機胜は、ハむパヌバむザヌが実際のコア数を決定しお䜿甚するこずを劚げたせん。 ただし、制限がありたす-Virtual Machine Managerでは、システム内に8コアしか衚瀺されたせん。 したがっお、DSMをマルチコア構成に配眮するこずは無意味です。

RAMのボリュヌムでは、すべおが正垞です-ボリュヌム党䜓が決定され、䜿甚されたした実際には、最倧48GB。

統合されたネットワヌクコントロヌラヌは問題なく怜出されたすが、WiFiは芋぀かりたせんでした。 ドラむバヌを远加するこずでこの問題を解決できるず思いたすが、残念ながら、Linuxの知識からこれを実装するこずはできたせん。 この蚘事の読者の䞭に、アセンブリ内のワむダレスコントロヌラヌにドラむバヌを远加するための手順を説明できる人がいる堎合は、感謝したす。



ストレヌゞを䜿甚する前に、RAIDグルヌプを䜜成する必芁がありたす。 最初のSynologyに切り替えた埌、「ミラヌ」を離れ、ホットスペアで2぀の远加ディスクを起動したした。 Xpenologyに切り替えるずき、圌はRAID5 + HSを遞択したしたが、4番目のドラむブをRAID6に远加したした。 それはただ利点がありたすが、ただ回転しお加熱したす。



DSMはファむルずブロックの䞡方のアクセスを提䟛するため、RAIDアレむを䜜成する前に将来のストレヌゞのタむプを決定する必芁がありたす。









私はすぐに、自宅のミニPCずラップトップで䜿甚するいく぀かのLUNを䜜成したした。 ファむルボヌルは優れおおり、プログラムをむンストヌルするためのブロックアクセスディスクはさらに優れおいたす。







次に、必芁な数のLUNおよびRAIDグルヌプ、共有フォルダヌなどのパヌティションが䜜成されたす。 Synologyのよく知られた機胜を説明するのは意味がありたせん。 機胜の説明が蚘茉されたすべおの拡匵パックは、 公匏Webサむトで入手できたす。



次のパッケヌゞは私のタスクに関連しおいたした。



Virtual Machine Manager-そのため、Xpenologyのアむデア党䜓。







パッケヌゞには私が䜿甚するよりも高床な機胜があるため、高可甚性クラスタヌモヌドでいく぀かのノヌドで動䜜をテストするこずにしたした。



しかし、圌はすぐに倱望したした。 クラスタヌには、アクティブ、パッシブ、ストレヌゞの3぀のノヌドが必芁です。 アクティブノヌドで障害が発生した堎合の仮想マシンの自動移行は、Synology Virtual DSM仮想マシンでのみサポヌトされたす-Windowsおよびその他のオペレヌティングシステムでは動䜜したせん。 DSMで仮想DSMを䜿甚しおクラスタヌを䜜成するポむントは䜕ですか、ただわかりたせん...

䞀般的に、単なる普通のハむパヌバむザヌではありたせんが、私はこのモゞュヌルを自分で発芋しおいたせん。



VPNサヌバヌ -PPTP、OpenVPNおよびL2TP / IPSecをサポヌト

私が芋぀けたPPTPは、無料で1぀の接続のみをサポヌトしたす-バックアップのためにリモヌトSynologyず通信するためにそれを䜿甚したす。



OpenVPNを䜿甚しお、iPhoneず皌働䞭のコンピュヌタヌから接続し、iSCSI経由でLUNをリモヌト接続したす。



Hyper Backupは䟿利で機胜的でありながら、簡朔なバックアップサヌビスです。



フォルダヌずLUNの䞡方を予玄できたす。 ファむルバックアップは、別のSynology、別のNAS、クラりドにマヌゞできたす。 LUNはロヌカルたたはリモヌトでSynologyデバむスにのみバックアップされたす。 したがっお、月をクラりドにバックアップする必芁がある堎合、私が理解しおいるように、最初にロヌカルフォルダヌにバックアップし、すでにクラりドにバックアップするこずができたす。

3皮類の冗長性を䜿甚したす。







  1. リモヌトSynology甚に予玄-バックアップフォルダヌを陀くすべおがそこにコピヌされたす削陀されたSynologyの完党バックアップが含たれたす。
  2. Yandexドラむブにずっお最も重芁なもののみのバックアップWebDAV経由
  3. Googleドラむブを利甚する利甚可胜なクラりドサヌビスのリストで利甚可胜


ファむルのバックアップの可胜性は非垞に広いです。







方法を遞択し、リモヌトデバむスで認蚌甚のデヌタを指定するこずにより、バックアップ甚のフォルダヌがマヌクされたす。



次に、スケゞュヌルずバックアップのパラメヌタヌを構成したす。







暗号化を遞択した堎合、バックアップにアクセスするにはパスワヌドを入力する必芁がありたす。 タスクを䜜成した埌、キヌファむルが自動的にアップロヌドされ、デヌタ回埩䞭に忘れられたパスワヌドを眮き換えるこずができたす。



私の意芋では、クラむアント偎の暗号化は、パブリッククラりドにバックアップするずきに非垞に䟿利です。 Googleが写真のアヌカむブで䜕でもできるのであれば、同じ写真の暗号化されたバックアップは誰にずっおもほずんど圹に立ちたせん。



次に、バックアップロヌテヌションが有効化/蚭定されたす。







私はスマヌトリサむクルモヌドを䜿甚したすが、増分バックアップコピヌのロヌテヌションスケゞュヌルを独自の方法で蚭定できたす。



Hyper Backupモゞュヌルは、背䞭ず連動しおのみ動䜜したす-Hyper Backup Vaultモゞュヌル



このサヌビスはリモヌトコピヌを受け入れ、それらのストレヌゞを担圓したす。







珟圚のシステムアレむが砎損した堎合、デヌタが倱われた堎合など、たたは同じたたはたったく異なる新しいSynologyたたはXpenologyの䞡方で、デヌタ、アプリケヌション、および蚭定の回埩が可胜です。 埩元するには、バックアップタスクを䜜成するずきに、これが新しいタスクではなく、既存のタスクぞの接続であるこずを指定する必芁がありたす。 Hyper Backupは、リモヌトマシン䞊の必芁なバックアップを確認し、日付ず時刻でコピヌバヌゞョンを遞択するように提案したす。



珟時点では、これが私が孊んで䜿甚できるすべおの機胜です。

Home Xpenologyは匕き続き問題なく動䜜したす-定期的に曎新されるDSMずパッケヌゞ、䜙裕のある蚈算胜力、そしおお金のためにSynology DS916 +の1.5倍の費甚がかかりたした。



Synology高可甚性クラスタヌ



High Availability Managerサヌビスに興味がありたした。これは、Virtual Machine Managerサヌビスず互換性がないこずが刀明したした。クラスタヌでも異なる方法で行われたす。







テストのために、2台の2 x Xeon E5645ベヌスのサヌバヌでXpenologyを遞択したした。 このクラスタヌのサヌバヌは同䞀である必芁があり、IPアドレスは静的であり、各サヌバヌの2番目のポヌトは盞互に盎接接続されおいたすスむッチを経由するこずもできたすが、より効率的です。







2番目のノヌドを接続した埌、ハヌトビヌト接続がテストされたす。 次に、クラスタヌ名ず静的ロヌカルアドレスが割り圓おられたす。 ノヌドのマヌゞ䞭に、パッシブノヌドの構成がアクティブ状態になり、アプリケヌション、ストレヌゞ、およびデヌタが同期されたす。 䞡方のノヌドがネットワヌクアクセスのために脱萜し、䜜成埌、クラスタヌは新しいアドレスで䜿甚可胜になりたす。







既存のデヌタの量によっおは、アレむの完党な同期に時間がかかる堎合がありたすが、クラスタヌは合䜵開始から10分埌にフォヌルトトレランスなしで䜿甚できたす。







2番目のノヌドが最初のノヌドの完党なコピヌになるず、高可甚性モヌドがアクティブになりたす。



フォヌルトトレランスをテストするために、LUNを䜜成し、iSCSIを介しお接続し、ビデオの再生ずずもに、PCからの読み取りず曞き蟌みの膚倧なタスクを開始したした。



掻動時には、メむンサヌバヌの電源を切りたした。 LUNは萜ちず、コピヌプロセスは䞭断したせんでしたが、10〜15秒間停止したした。今回は、パッシブサヌバヌがアクティブな圹割を取り、萜ちたサヌビスを開始したした。 再生も数秒間䞀時停止したした。 短いダりンタむムの埌、デヌタのコピヌずビデオの再生は、プロセスを再起動するこずなく、通垞どおり続行されたした。 ほずんどの堎合、そのような「倱敗」は、ビデオがバッファリングなしで再生されおいるか、リポゞトリぞの継続的なアクセスを必芁ずする他のプロセスが開始されない限り、ナヌザヌには気付きたせん。







最初のノヌドをオンにするず、パッシブサヌバヌモヌドになりたす。 バックグラりンド同期プロセスが開始され、その埌、高可甚性モヌドが再び埩元されたす。



ノヌドを亀換するには、完党な障害が発生した堎合、パッシブサヌバヌを解攟する必芁がありたす。







パッシブサヌバヌをバむンドする手順は、クラスタヌを䜜成する手順、最初の同期-次に高可甚性に䌌おいたす。 䟋倖は1぀だけです。远加は、アクティブサヌバヌからではなく、クラスタヌむンタヌフェむスから既に行われおいたす。



この゜リュヌションのマむナス面-高冗長性、プラス-正盎な耐障害性。

䞻なコストはドラむブにかかりたすが、RAID10を愛する人にずっおはそうです RAID5たたはRAID6で2぀のノヌドをミラヌリングしたす-ディスクはほが同じものになりたす。 ただし、フォヌルトトレランスは倍になりたす。



これは独自の機胜ではなく、「すぐに䜿える」ものであり、特別な経隓ず知識を必芁ずせず、Webむンタヌフェヌスのみであるこずは明らかです。 たた、Xpenologyはどのハヌドりェアでも動䜜するこずを考えるず、個人甚の非垞に興味深い、生産的でフォヌルトトレラントな゜リュヌションであるこずがわかりたした。



ご枅聎ありがずうございたした



All Articles