1C 開発者の物語: 管理者の物語

すべての 1C 開発者は、何らかの形で IT サービスと密接にやり取りし、システム管理者と直接やり取りします。 しかし、このやり取りは必ずしもスムーズに進むわけではありません。 これについていくつか面白い話をしたいと思います。

高速通信チャネル

当社のクライアントのほとんどは、独自に大規模な IT 部門を有する大企業です。 また、クライアントのスペシャリストは通常​​、情報データベースのバックアップ コピーを担当します。 しかし、比較的小規模な組織もあります。 特に彼らのために、私たちはすべての 1C のバックアップに関連するすべての問題を自分たちで引き受けるサービスを提供しています。 これが今回の話で取り上げる会社です。

新しいクライアントが 1C をサポートするようになり、契約には、独自のシステム管理者がスタッフとして配置されていたものの、特にバックアップの責任を負うという条項が含まれていました。 クライアントサーバー データベース、DBMS としての MS SQL。 かなり標準的な状況ですが、まだニュアンスが XNUMX つあります。それは、主要拠点が非常に大きいにもかかわらず、毎月の増加が非常に小さいということです。 つまり、データベースには大量の履歴データが含まれていました。 この機能を考慮して、私は次のようにバックアップ メンテナンス プランを設定しました。毎月第 XNUMX 土曜日に完全バックアップが作成され、それは非常に重く、その後、差分コピーが毎晩作成されました。比較的小さなボリュームで、コピーが XNUMX つ作成されました。トランザクション ログを XNUMX 時間ごとに記録します。 さらに、完全コピーと差分コピーはネットワーク リソースにコピーされただけでなく、FTP サーバーにも追加でアップロードされました。 これは本サービスを提供する際の必須要件です。

これらはすべて正常に構成され、運用され、通常は障害なく動作しました。

しかし、数か月後、この組織のシステム管理者が変わりました。 新しいシステム管理者は、現代のトレンドに合わせて会社の IT インフラストラクチャを徐々に再構築し始めました。 特に、仮想化が登場し、ディスクシェルフが登場し、あらゆる場所でアクセスがブロックされたなど、一般的な場合にはもちろん喜ばざるを得ません。 しかし、物事は常に順調に進んだわけではなく、1C のパフォーマンスにしばしば問題が発生し、それが私たちのサポートとの意見の相違や誤解を引き起こしました。 また、彼との関係は一般的に非常に冷たく、やや緊張したものであり、問​​題が発生した場合には緊張の度合いが増すだけだったということにも注意しなければなりません。

しかし、ある朝、このクライアントのサーバーが利用できないことが判明しました。 何が起こったのかシステム管理者に電話したところ、「サーバーがクラッシュしました。現在対応中です。あなたの責任ではありません。」というような答えが返されました。 まあ、彼らがうまくいくのは良いことだ。 これは状況が制御下にあることを意味します。 昼食後、もう一度電話をかけてみると、管理者の声にはイライラの代わりに疲労感と無関心がすでに感じられました。 何が起こったのか調べているのですが、何かお手伝いできることはありますか? 話し合いの結果、次のようなことが分かりました。

彼は、新しく組み立てられた RAID を備えた新しいストレージ システムにサーバーを移動しました。 しかし、何か問題が発生し、数日後、この襲撃は無事に崩壊しました。 コントローラーが焼き切れたのか、ディスクに何かが起こったのか、正確には覚えていませんが、すべての情報が回復不可能なほど失われてしまいました。 そして重要なことは、さまざまな移行中に、バックアップを含むネットワーク リソースも同じディスク アレイ上に配置されることになりました。 つまり、本稼働データベース自体とそのすべてのバックアップ コピーの両方が失われました。 そして今何をすべきかは不明です。

落ち着け、と私は言います。 夜間のバックアップがあります。 それに応じて沈黙があり、それによって私はたった今、一人の人の命を救ったことに気づきました。 このコピーを新しく展開されたサーバーに転送する方法について説明します。 しかし、ここでも問題が発生しました。

完全バックアップは非常に大きいと言ったときのことを覚えていますか? 月に一度、土曜日にそれを行ったのも無駄ではありませんでした。 実際のところ、その会社は都市から遠く離れたところにある小さな工場で、インターネットの接続もまあまあでした。 月曜日の朝までに、つまり週末にかけて、このコピーはかろうじて FTP サーバーにアップロードされました。 しかし、逆方向に読み込まれるまで XNUMX ～ XNUMX 日待つことはできませんでした。 ファイルの転送を何度か試みて失敗した後、管理者は新しいサーバーからハードドライブを直接取り出し、どこかで運転手付きの車を見つけてすぐに私たちのオフィスに駆けつけました。幸いにも私たちはまだ同じ市内にいます。

彼らがサーバー ルームに立ってファイルがコピーされるのを待っている間、私たちはいわば「直接」初めて会い、コーヒーを飲みながら、カジュアルな雰囲気で話をしました。 私は彼の悲しみに同情し、完全なバックアップを持って彼を送り返し、停止した会社の業務を急いで復旧させました。

その後、IT 部門に対するすべてのリクエストは非常に迅速に解決され、意見の相違はなくなりました。

システム管理者に連絡してください

かつて、非常に長い間、1 つのクライアントに対して IIS 経由の Web アクセス用に 1C を公開できませんでした。 それは平凡なタスクのように見えましたが、すべてを実行する方法はありませんでした。 ローカルのシステム管理者も参加し、さまざまな設定と構成ファイルを試しました。 ウェブ上の XNUMXC は通常、いかなる形でも働きたくありませんでした。 ドメイン セキュリティ ポリシー、またはローカルの高度なファイアウォールに何か問題があったのか、それとも他に何があるかは神のみぞ知るです。 N 回目の反復で、管理者は次の文言を含むリンクを私に送信します。

- これらの手順に従ってもう一度試してください。 そこにはすべてが非常に詳細に説明されています。 それがうまくいかない場合は、このサイトの作者に手紙を書いてください。おそらく彼が助けてくれるでしょう。
「いいえ、役に立ちません」と私は言いました。
- Почему？
— 私はこのサイトの著者です... (

結果、問題なくApache上で起動できました。 IISは決して敗北しませんでした。

もう一段階深くなった

私たちのクライアントは小規模の製造企業でした。 彼らは、ターミナル サーバー + アプリケーション サーバー + データベース サーバーという、一種の「古典的な」3 in 1 サーバーを持っていました。 彼らは UPP に基づいた業界固有の構成で動作し、ユーザー数は約 15 ～ 20 人で、システムのパフォーマンスは原則として誰にでも適していました。

時間が経つにつれて、すべてが多かれ少なかれ安定して動作するようになりました。 しかしその後、ヨーロッパがロシアに対して制裁を課したため、ロシア人は主に国産製品を購入するようになり、この会社の業績は急激に悪化した。 ユーザー数は 50 ～ 60 名に増加し、新しい支店が開設され、それに応じて書類の流れも増加しました。 そして現在、現在のサーバーは負荷の急激な増加に対応できなくなり、1C が「速度が低下」し始めたと言われています。 ピーク時には、ドキュメントの処理に数分間かかり、ブロック エラーが発生し、フォームを開くのに長い時間がかかり、その他の一連の関連サービスもすべて停止していました。 地元のシステム管理者は、「これはあなたの 1C です。あなたが解決してくれるでしょう。」と言ってすべての問題を無視しました。 私たちはシステムのパフォーマンス監査の実施を繰り返し提案してきましたが、監査そのものには至りませんでした。 クライアントは単に問題を解決する方法についての推奨事項を求めただけです。

さて、私は座って、DBMS によるターミナル サーバーとアプリケーション サーバーの役割を分離する必要性について、かなり長い手紙を書きました (原則として、これまでに何度も述べてきました)。 私はターミナル サーバー上の DFSS や共有メモリについて書き、信頼できる情報源へのリンクを提供し、さらには機器のいくつかのオプションについても提案しました。 この手紙は社内の権力者に届き、「実装する」という決議とともにIT部門に戻り、全体的に氷は解けました。

しばらくして、管理者から新しいサーバーの IP アドレスとログイン資格情報が送信されます。 MS SQL と 1C サーバー コンポーネントがそこにデプロイされており、データベースを転送する必要があるが、1C キーでいくつかの問題が発生したため、現時点では DBMS サーバーにのみ転送する必要があると彼は言います。

確かに、すべてのサービスが実行されており、サーバーはそれほど強力ではありませんでしたが、まあ、何もしないよりはマシだと思います。 現在のサーバーを何とか軽減するために、とりあえずデータベースを移転します。 合意された時間にすべての転送を完了しましたが、状況は変わらず、パフォーマンスの問題は依然として同じでした。 もちろんそれは奇妙ですが、データベースを 1C クラスターに登録してみましょう。

数日経ちますが、鍵は転送されません。 何が問題なのか気になりますが、すべては単純なようです。あるサーバーからそれを取り出し、別のサーバーに接続し、ドライバーをインストールすれば完了です。 管理者は、ポート転送や仮想サーバーなどについて大騒ぎして何かを言うことで応答します。

うーん…仮想サーバー？ 仮想化はこれまで一度も行われなかったようです... Windows Server 1 の Hyper-V 上の仮想マシンに 2008C サーバー キーを転送できないというかなり有名な問題を覚えています。そしてここにあります。私の中でいくつかの疑惑が生まれ始めます...

サーバー マネージャーを開く - [役割] - 新しい役割 - Hyper-V が表示されます。 Hyper-V マネージャーにアクセスし、XNUMX つの仮想マシンを確認し、接続します...そして確かに...新しいデータベース サーバー...

だから何？ 当局の指示と私の勧告は実行され、役割は分離されました。 タスクを閉じることができます。

しばらくして、現在の危機が発生し、新しいブランチを閉鎖する必要があり、負荷が減少し、システムのパフォーマンスはある程度耐えられるようになりました。

もちろん、サーバーキーを仮想マシンに転送することはできませんでした。 その結果、物理マシン上のターミナル サーバー + 1C クラスター、仮想マシン上のデータベース サーバーというすべてがそのまま残されました。

そして、これがシャラシキンのオフィスのようなものだったら素晴らしいでしょう。 いいえ。 有名な企業で、その製品はおそらくすべてのレンタスとオーシャンの関連部門で目にしたことがあるでしょう。

ハードドライブ休暇のスケジュール

世界征服という野心的な計画を持つ大規模な持ち株会社が、巨大企業に組み込むことを目的として、再び中小企業を買収した。 この所蔵のすべての部門で、ユーザーは独自のデータベースで作業しますが、同じ構成を使用します。 そこで私たちは、このシステムに新しいユニットを組み込むための小さなプロジェクトを開始しました。

まず、実稼働データベースとテスト データベースを展開する必要があります。 開発者は接続データを受信し、サーバーにログインすると、MS SQL がインストールされていること、1C サーバーが表示され、2 つの論理ドライブ (容量が 250 ギガバイトのドライブ「C」と容量が 1 テラバイトのドライブ「D」) が表示されます。 「C」はシステム、「D」はデータで、開発者は論理的にすべてのデータベースを決定し、そこにデプロイします。 万が一に備えて、バックアップを含むメンテナンス計画も立てています（これについては責任を負いませんが）。 確かに、バックアップはここ「D」に追加されました。 将来的には、別のネットワーク リソースに再構成することが計画されています。

プロジェクトが開始され、コンサルタントが新しいシステムでの作業方法に関するトレーニングを提供し、残りの部分が転送され、いくつかの小さな改良が加えられ、ユーザーは新しい情報ベースで作業を開始しました。

ある月曜の朝、データベース ディスクが見つからないことが判明するまでは、すべてが順調でした。 サーバーには「D」が存在しないだけです。

さらに調査を進めると、この「サーバー」は実際にはローカル システム管理者の仕事用コンピューターであることが判明しました。 確かに、サーバー OS はまだありました。 この管理者の個人用 USB ドライブがサーバーに接続されていました。 そこで管理者は、旅行中に映画を送り込むことを目的として、ネジを持って休暇に出かけました。

ありがたいことに、彼はデータベース ファイルを削除することなく、生産的なデータベースを復元することができました。

USB ドライブにあるシステムのパフォーマンスに全員が概ね満足していたことは注目に値します。 1C の不満足なパフォーマンスについて誰も文句を言いませんでした。 ホールディングがすべての情報データベースを、スーパーサーバー、1万ルーブル以上のストレージシステム、洗練されたハイパーバイザー、そしてすべての支店に耐え難いXNUMXCブレーキを備えた単一の集中サイトに転送するという巨大プロジェクトを開始したのはさらに後になってからのことだった。

しかし、それはまったく別の話です...

出所： habr.com