高速通信チャネル
私たちの顧客のほとんどは、大規模なIT部門を持つ大規模な持ち株です。 原則として、情報ベースのバックアップコピーについては、クライアントの専門家が責任を負います。 しかし、比較的小さな組織があります。 特に彼らには、すべての1Cのバックアップに関連するすべての問題を処理するサービスがあります。 このような企業については、このストーリーで説明します。
新しいクライアントが1Cをサポートするようになり、特に契約にはバックアップに責任があるという条項が含まれていましたが、スタッフには独自のシステム管理者がいました。 DBMS-MS SQLとしてのクライアント/サーバーデータベース。 かなり標準的な状況ですが、それでも1つのニュアンスがありました。メインベースは非常に大きかったのですが、同時に毎月の増加は非常に小さかったです。 つまり、データベースには多くの履歴データが含まれていました。 この特性を考慮して、私は次のようにバックアップメンテナンスプランを設定しました。毎月第1土曜日に完全バックアップが作成され、非常に重く、毎晩差分コピーが作成されました-比較的小さなボリュームとトランザクションログコピーが1時間ごとに作成されました。 さらに、ネットワークリソースにコピーされたというだけでなく、完全および差分コピーもFTPサーバーにアップロードされました。 これは、このサービスを提供するための必須要件です。
これらのすべてが正常に構成され、運用され、一般に確実に機能しました。
しかし、数か月後、システム管理者はこの組織で変更しました。 新しいシステム管理者は、現代の傾向に従って会社のITインフラストラクチャを徐々に再構築し始めました。 特に、仮想化が登場し、ディスクシェルフがあり、アクセスはどこでも閉じられ、すべてなどがありましたが、これは一般的なケースではもちろん喜ばしいことです。 しかし、それは彼と常にスムーズに行くとは限らず、しばしば1Cのパフォーマンスに問題があり、それが私たちのサポートとの不一致と誤解を引き起こしました。 また、彼との関係は一般に非常に寒く、やや緊張しており、問題が発生した場合に緊張度を高めるだけであることに注意する必要があります。
しかし、ある朝、このクライアントのサーバーが利用できないことが判明しました。 システム管理者に電話して、何が起こったのかを確認し、「サーバーがクラッシュしました。作業中です。あなた次第ではありません。」 まあ、それは動作します。 したがって、状況は制御されています。 昼食後、私は管理者の声で再び電話をかけます。いらいらする代わりに、私はすでに疲れと無関心を感じています。 何が起こったのかを明確にしようとしていますが、どうにかして手助けできますか？ 会話の結果、次のことが明らかになりました。
彼は、組み立てたばかりのRAIDを備えた新しいストレージシステムにサーバーを移動しました。 しかし、何かがうまくいかず、数日後にこの襲撃は無事に崩れ落ちました。 コントローラーが焼損したか、ディスクに何かが起こった場合、正確には覚えていませんが、すべての情報は回復不能なほど失われました。 そして、主なことは、移行の過程でもバックアップを備えたネットワークリソースが同じディスクアレイ上にあったことです。 つまり、本稼働ベース自体とそのすべてのバックアップの両方が失われました。 そして今何をすべきかは明らかではありません。
穏やかに、私は言います。 夜のバックアップがあります。 答えは沈黙であり、それによって私は人の命を救っただけだと理解しています。 このコピーを展開したばかりの新しいサーバーに転送する方法について説明し始めます。 しかし、ここで問題が発生しました。
完全なバックアップが非常に大きいと言ったことを覚えていますか？ 私は月に一度土曜日に正当な理由でそれをしました。 事実、会社は小さな工場であり、市のはるか遠くにあり、彼らが持っていたインターネットはまあまあだったということです。 月曜日の朝まで、つまり週末に、悲しみの半分になったこのコピーには、FTPサーバーにアップロードする時間がありました。 しかし、逆方向に起動するまで1〜2日待つことはできませんでした。 ファイルのドラッグに何度か失敗した後、管理者は新しいサーバーから直接ハードドライブを取り出し、ドライバーのいる車を見つけて、すぐに私たちのオフィスに急ぎました。
サーバールームに立ち、ファイルがコピーされるのを待っている間に、いわば「ライブ」に会い、コーヒーを飲み、非公式の場で話しました。 私は彼の悲しみに同情し、バックアップの完全なねじで送り返し、急いで会社の仕事を取り戻しました。
その後、IT部門へのすべてのアプリケーションは非常に迅速に解決され、意見の相違はなくなりました。
システム管理者に連絡してください
一度、あるクライアントに対して、非常に長い間、IISを介したWebアクセス用に1Cを公開できませんでした。 普通のタスクのようですが、ここではうまくいきませんでした。 ローカルシステム管理者が接続し、さまざまな設定および構成ファイルを試しました。 Web上の1Cは、通常、いずれでも動作することを望みませんでした。 ドメインセキュリティポリシー、ローカルの洗練されたファイアウォール、または何が問題なのか。 N回目の繰り返しで、管理者は次の単語を含むリンクをドロップします。
-この手順で再試行してください。 ここではすべてが非常に詳細です。 うまくいかない場合は、このサイトの著者に手紙を書いてください。おそらく彼が助けてくれるでしょう。
「いいえ」と私は言います、「それは助けにはなりません。」
-なんで？
-私はこのサイトの著者です...（
その結果、Apacheは問題なく起動しました。 IISは勝つことができませんでした。
より深く
クライアントがいました-小さな製造企業。 サーバーには、ターミナルサーバー+アプリケーションサーバー+データベースサーバーという、独特な「クラシック」な3対1のサーバーがありました。 彼らはソフトスターターに基づいた特定の業界構成で働いており、原則としてシステムパフォーマンスは15〜20人のユーザーがいました。
時間が経ち、すべてがほぼ安定して動作しました。 しかし、ヨーロッパはロシアに対して制裁を課し、その結果、ロシア人は主に国内製品を購入し始め、この会社との取引は困難になりました。 ユーザーの数は50〜60人に増え、新しいブランチがオープンし、ワークフローも増えました。 そして今、現在のサーバーは劇的に増加した負荷に対処するのをやめ、1Cは「スローダウン」と言うように開始しました。 ピーク時には、ドキュメントが数分間保持され、ブロッキングエラーが降ったり、フォームが長時間開かれたり、その他すべての関連サービスが行われたりしました。 ローカルシステム管理者はすべての問題を却下し、「これはあなたの1Cです。あなたはそれを把握する必要があります。」と言いました。 システムのパフォーマンスを監査することを繰り返し提案しましたが、これは監査そのものには至りませんでした。 クライアントは、単にトラブルシューティングに関する推奨事項を求めました。
さて、私は座って、ターミナルサーバーとアプリケーションサーバーの役割をDBMSから分離する必要があることを示すかなり大量の手紙を書きました（原則として、以前繰り返しました）。 ターミナルサーバー上のDFSSについて、共有メモリについて書いて、信頼できるソースへのリンクを投げ、さらにいくつかのハードウェアオプションを提供しました。 この手紙は会社の権力に届き、「実行」決議でIT部門に伝えられ、一般的に氷が壊れました。
しばらくすると、管理者から新しいサーバーのIPアドレスとログイン資格情報が送信されます。 彼は、MS SQLと1Cサーバーのコンポーネントがそこにデプロイされており、データベースを転送する必要があると言いますが、1Cキーにはいくつかの問題があるため、これまでのところDBMSサーバーにのみ転送する必要があります。
実際、すべてのサービスが入って来ましたが、サーバーはあまり強力ではありません、大丈夫、何もないよりはましだと思います。 これまでのデータベースを転送して、少なくとも何らかの形で現在のサーバーを解放します。 交渉された時間に、彼はすべての転送を実行しましたが、状況は変わりませんでした-すべて同じパフォーマンスの問題。 奇妙なことですが、もちろん、1Cクラスターにベースを登録してみましょう。
数日かかりますが、キーは転送されていません。 私は問題が何であるかに興味があり、すべてが単純なようです-あるサーバーからそれを削除し、別のサーバーに貼り付け、ドライバーをインストールし、準備ができました。 管理者が応答し、ポート転送、仮想サーバーなどについて何か言います。
うーん...仮想サーバー？ 仮想化は一度もなかったようで、そうではなかったようです... Windows Server 2008のHyper-Vで仮想マシンに1Cサーバーキーを転送できないというかなりよく知られている問題を思い出します。
サーバーマネージャーを開きます-役割-新しい役割が現れました-Hyper-V。 Hyper-Vマネージャーに移動し、1台の仮想マシンが表示され、接続しています...そして本当に...新しいデータベースサーバー...
まあ、何？ 当局の指示と私の推奨事項は満たされ、役割は分離されています。 タスクを閉じることができます。
しばらくして、危機が起こり、新しいブランチを閉じる必要があり、負荷が減少し、システムのパフォーマンスが多少なりとも許容範囲になりました。
ただし、サーバーキーを仮想マシンに転送することはできません。 その結果、物理マシン上のターミナルサーバー+ 1Cクラスター、仮想マシン内の同じ場所にあるデータベースサーバーなど、すべてが現状のままで残っていました。
そして大丈夫、それはある種のシャラスキン事務所でしょうか。 だから よく知られた会社。その製品は、あらゆる種類のリボンとアウチャノフの対応する部門でおそらく知っていて見たことがあるでしょう。
ハードドライブの休暇スケジュール
まず、戦闘基地とテスト基地を展開する必要があります。 開発者は、接続のデータを受け取り、サーバーにログオンし、インストールされたMS SQL、1Cサーバー、2つの論理ドライブ（250ギガバイトのCドライブと1テラバイトのDドライブ）を確認します。 「C」はシステム、「D」はデータ、開発者はそこにあるすべてのデータベースを論理的に決定して展開します。 万が一の場合に備えて、バックアップを含むメンテナンスプランを設定しました（これについては責任を負いませんが）。 真のバックアップは「D」でここで形になりました。 将来的には、いくつかの個別のネットワークリソースで既に再構成することが計画されていました。
プロジェクトが開始され、コンサルタントが新しいシステムでの作業方法に関するトレーニングを実施し、残り物が移され、いくつかの小さな点が改善され、ユーザーは新しい情報ベースですでに作業を開始しました。
すべてが順調に進み、月曜日のある朝まで、データベースドライブが消失したことが発見されました。 サーバーには単に「D」はなく、それだけです。
さらなる調査により、これが明らかになりました。実際、この「サーバー」はローカルシステム管理者の作業コンピューターでした。 確かに、サーバーOSはまだその上にありました。 この管理者の個人用USBディスクがサーバーに挿入されました。 そして、管理者は休暇中に彼自身のネジを持って行き、道路に映画を送り込むことを目標にした。
神に感謝します、彼は何とかデータベースファイルを削除することができず、作業中のデータベースを復元することができました。
一般に、誰もがUSBドライブにあるシステムのパフォーマンスに満足していることは注目に値します。 1Cの不満足な作業について不満を言う人はいませんでした。 メガプロジェクトは、すべての情報データベースをスーパーサーバー、100万+ルーブルのストレージ、洗練されたハイパーバイザー、すべての支社で耐えられない1Cブレーキを備えた単一の中央プラットフォームに転送することから始まりました。
しかし、これは全く異なる話です...