1C বিকাশকারীর গল্প: অ্যাডমিনের

সমস্ত 1C বিকাশকারীরা এক বা অন্যভাবে আইটি পরিষেবাগুলির সাথে এবং সরাসরি সিস্টেম প্রশাসকদের সাথে ঘনিষ্ঠভাবে যোগাযোগ করে। কিন্তু এই মিথস্ক্রিয়া সবসময় মসৃণভাবে যায় না। আমি এই সম্পর্কে কিছু মজার গল্প বলতে চাই.

উচ্চ গতির যোগাযোগ চ্যানেল

আমাদের ক্লায়েন্টদের বেশিরভাগই তাদের নিজস্ব বড় আইটি বিভাগের সাথে বড় হোল্ডিং। এবং ক্লায়েন্ট বিশেষজ্ঞরা সাধারণত তথ্য ডাটাবেসের ব্যাকআপ কপিগুলির জন্য দায়ী। তবে তুলনামূলকভাবে ছোট প্রতিষ্ঠানও রয়েছে। বিশেষ করে তাদের জন্য, আমাদের একটি পরিষেবা রয়েছে যা অনুসারে আমরা 1C সবকিছুর ব্যাকআপ সম্পর্কিত সমস্ত সমস্যা নিজেরাই গ্রহণ করি। আমরা এই গল্পে এই কোম্পানির কথা বলব।

একটি নতুন ক্লায়েন্ট 1C সমর্থন করতে এসেছিল এবং অন্যান্য জিনিসগুলির মধ্যে, চুক্তিতে একটি ধারা অন্তর্ভুক্ত ছিল যে আমরা ব্যাকআপের জন্য দায়ী, যদিও তাদের কর্মীদের নিজস্ব সিস্টেম অ্যাডমিনিস্ট্রেটর ছিল। ক্লায়েন্ট-সার্ভার ডাটাবেস, MS SQL একটি DBMS হিসাবে। একটি মোটামুটি স্ট্যান্ডার্ড পরিস্থিতি, তবে এখনও একটি সূক্ষ্মতা ছিল: মূল ভিত্তিটি বেশ বড় ছিল, তবে মাসিক বৃদ্ধি খুব ছোট ছিল। অর্থাৎ ডাটাবেসে প্রচুর ঐতিহাসিক তথ্য ছিল। এই বৈশিষ্ট্যটি বিবেচনায় নিয়ে, আমি নিম্নরূপ ব্যাকআপ রক্ষণাবেক্ষণ পরিকল্পনা সেট করেছি: প্রতি মাসের প্রথম শনিবার একটি সম্পূর্ণ ব্যাকআপ তৈরি করা হয়েছিল, এটি বেশ ভারী ছিল, তারপর প্রতি রাতে একটি ডিফারেনশিয়াল কপি তৈরি করা হয়েছিল - একটি অপেক্ষাকৃত ছোট ভলিউম এবং একটি অনুলিপি প্রতি ঘন্টায় লেনদেনের লগ। অধিকন্তু, সম্পূর্ণ এবং ডিফারেনশিয়াল কপিগুলি শুধুমাত্র একটি নেটওয়ার্ক সংস্থানে অনুলিপি করা হয়নি, তবে অতিরিক্তভাবে আমাদের FTP সার্ভারে আপলোড করা হয়েছে৷ এই পরিষেবা প্রদান করার সময় এটি একটি বাধ্যতামূলক প্রয়োজন।

এই সমস্ত সফলভাবে কনফিগার করা হয়েছিল, অপারেশন করা হয়েছিল এবং সাধারণত ব্যর্থতা ছাড়াই কাজ করেছিল।

কিন্তু কয়েক মাস পরে, এই সংস্থার সিস্টেম প্রশাসক পরিবর্তন হয়। নতুন সিস্টেম অ্যাডমিনিস্ট্রেটর ধীরে ধীরে আধুনিক প্রবণতা অনুসারে কোম্পানির আইটি অবকাঠামো পুনর্নির্মাণ করতে শুরু করে। বিশেষত, ভার্চুয়ালাইজেশন উপস্থিত হয়েছিল, ডিস্কের তাক, অ্যাক্সেস সর্বত্র অবরুদ্ধ ছিল এবং সবকিছু ইত্যাদি, যা সাধারণ ক্ষেত্রে অবশ্যই আনন্দ করতে পারে না। কিন্তু জিনিসগুলি সবসময় তার জন্য মসৃণ ছিল না; প্রায়শই 1C-এর পারফরম্যান্সের সাথে সমস্যা ছিল, যা আমাদের সমর্থনের সাথে কিছু মতবিরোধ এবং ভুল বোঝাবুঝির কারণ ছিল। এছাড়াও, এটি লক্ষ করা উচিত যে তার সাথে আমাদের সম্পর্ক সাধারণত বেশ ঠাণ্ডা এবং কিছুটা উত্তেজনাপূর্ণ ছিল, যা কোনও সমস্যা দেখা দিলেই কেবল উত্তেজনার মাত্রা বাড়িয়েছিল।

কিন্তু একদিন সকালে দেখা গেল যে এই ক্লায়েন্টের সার্ভারটি অনুপলব্ধ। আমি সিস্টেম অ্যাডমিনিস্ট্রেটরকে কল করেছিলাম কি ঘটেছে তা জানতে এবং একটি উত্তর হিসাবে কিছু পেয়েছি যেমন "আমাদের সার্ভার ক্র্যাশ হয়েছে, আমরা এটি নিয়ে কাজ করছি, আপনার উপর নয়।" ওয়েল, এটা ভাল যে তারা কাজ. এর মানে পরিস্থিতি নিয়ন্ত্রণে রয়েছে। দুপুরের খাবারের পরে, আমি আবার কল করি এবং বিরক্তির পরিবর্তে, আমি ইতিমধ্যে অ্যাডমিনের কণ্ঠে ক্লান্তি এবং উদাসীনতা অনুভব করতে পারি। আমি কি ঘটেছে তা বের করার চেষ্টা করছি এবং সাহায্য করার জন্য আমরা কিছু করতে পারি কি? কথোপকথনের ফলস্বরূপ, নিম্নলিখিতগুলি আবির্ভূত হয়েছিল:

তিনি নতুন একত্রিত অভিযানের সাথে সার্ভারটিকে একটি নতুন স্টোরেজ সিস্টেমে স্থানান্তরিত করেছেন। কিন্তু কিছু ভুল হয়েছে এবং কয়েকদিন পরে এই অভিযানটি নিরাপদে ভেঙে পড়ে। কন্ট্রোলারটি পুড়ে গেছে বা ডিস্কগুলিতে কিছু ঘটেছে কিনা, আমি ঠিক মনে করি না, তবে সমস্ত তথ্য অপ্রত্যাশিতভাবে হারিয়ে গেছে। এবং প্রধান জিনিসটি ছিল যে ব্যাকআপ সহ নেটওয়ার্ক সংস্থানটি বিভিন্ন স্থানান্তরের সময় একই ডিস্ক অ্যারেতে শেষ হয়েছিল। অর্থাৎ, উৎপাদনশীল ডাটাবেস এবং এর সমস্ত ব্যাকআপ কপি উভয়ই হারিয়ে গেছে। এবং এখন কি করতে হবে তা স্পষ্ট নয়।

শান্ত হও, আমি বলি। আমরা আপনার রাতের ব্যাকআপ আছে. জবাবে, নীরবতা ছিল, যার দ্বারা আমি বুঝতে পেরেছিলাম যে আমি একজন মানুষের জীবন বাঁচিয়েছি। এই অনুলিপিটি কীভাবে একটি নতুন, সদ্য স্থাপন করা সার্ভারে স্থানান্তর করা যায় তা নিয়ে আমরা আলোচনা শুরু করি। কিন্তু এখানেও একটা সমস্যা দেখা দিল।

মনে আছে যখন আমি বলেছিলাম যে পুরো ব্যাকআপটি বেশ বড় ছিল? এটা কোন কিছুর জন্য ছিল না যে আমি মাসে একবার শনিবার এটি করতাম। আসল বিষয়টি হ'ল সংস্থাটি একটি ছোট প্ল্যান্ট ছিল, যা শহরের বাইরে অবস্থিত ছিল এবং তাদের ইন্টারনেট ছিল খুব তাই। সোমবার সকালের মধ্যে, অর্থাৎ সপ্তাহান্তে, এই কপিটি আমাদের FTP সার্ভারে আপলোড করা সম্ভব হয়নি। কিন্তু বিপরীত দিকে লোড হওয়ার জন্য এক বা দুই দিন অপেক্ষা করার উপায় ছিল না। ফাইলটি স্থানান্তর করার জন্য বেশ কয়েকটি অসফল প্রচেষ্টার পরে, প্রশাসক নতুন সার্ভার থেকে সরাসরি হার্ড ড্রাইভটি নিয়েছিলেন, কোথাও একজন ড্রাইভার সহ একটি গাড়ি খুঁজে পেয়েছেন এবং দ্রুত আমাদের অফিসে ছুটে গেছেন, ভাগ্যক্রমে আমরা এখনও একই শহরে আছি।

যখন তারা আমাদের সার্ভার রুমে দাঁড়িয়ে ফাইলগুলি কপি করার জন্য অপেক্ষা করছিল, আমরা প্রথমবারের মতো দেখা করলাম, তাই কথা বলার জন্য, "ব্যক্তিগতভাবে" এক কাপ কফি পান করলাম, এবং একটি অনানুষ্ঠানিক পরিবেশে কথা বললাম। আমি তার দুঃখের প্রতি সহানুভূতি জানিয়েছিলাম এবং তাকে ব্যাকআপের সম্পূর্ণ স্ক্রু দিয়ে ফেরত পাঠিয়েছিলাম, দ্রুত কোম্পানির বন্ধ কাজ পুনরুদ্ধার করে।

পরবর্তীকালে, আইটি বিভাগের কাছে আমাদের সমস্ত অনুরোধ খুব দ্রুত সমাধান করা হয়েছিল এবং আর কোন মতবিরোধ দেখা দেয়নি।

আপনার সিস্টেম অ্যাডমিনিস্ট্রেটরের সাথে যোগাযোগ করুন

একবার, খুব দীর্ঘ সময়ের জন্য, আমি একজন ক্লায়েন্টের জন্য IIS এর মাধ্যমে ওয়েব অ্যাক্সেসের জন্য 1C প্রকাশ করতে পারিনি। এটি একটি সাধারণ কাজ বলে মনে হয়েছিল, কিন্তু সবকিছু চালানোর কোন উপায় ছিল না। স্থানীয় সিস্টেম অ্যাডমিনিস্ট্রেটররা জড়িত এবং বিভিন্ন সেটিংস এবং কনফিগারেশন ফাইল চেষ্টা করে। ওয়েবে 1C সাধারণত কোনোভাবেই কাজ করতে চায় না। কিছু ভুল ছিল, হয় ডোমেন নিরাপত্তা নীতির সাথে, বা স্থানীয় অত্যাধুনিক ফায়ারওয়ালের সাথে, বা ঈশ্বর জানেন আর কি। Nth পুনরাবৃত্তিতে, প্রশাসক আমাকে এই শব্দগুলির সাথে একটি লিঙ্ক পাঠান:

- এই নির্দেশাবলী ব্যবহার করে আবার চেষ্টা করুন. সেখানে সবকিছু বিস্তারিতভাবে বর্ণনা করা হয়েছে। যদি এটি কাজ না করে, এই সাইটের লেখককে লিখুন, সম্ভবত তিনি সাহায্য করতে পারেন।
"না," আমি বলি, "এটা সাহায্য করবে না।"
- কেন?
— আমি এই সাইটের লেখক...(

ফলস্বরূপ, আমরা কোন সমস্যা ছাড়াই Apache এ এটি চালু করেছি। আইআইএস কখনই পরাজিত হয়নি।

এক স্তর গভীরে

আমাদের একটি ক্লায়েন্ট ছিল - একটি ছোট উত্পাদন উদ্যোগ। তাদের একটি সার্ভার ছিল, এক ধরনের "ক্লাসিক" 3 ইন 1: টার্মিনাল সার্ভার + অ্যাপ্লিকেশন সার্ভার + ডাটাবেস সার্ভার। তারা ইউপিপি-র উপর ভিত্তি করে কিছু শিল্প-নির্দিষ্ট কনফিগারেশনে কাজ করেছিল, প্রায় 15-20 জন ব্যবহারকারী ছিল এবং সিস্টেমের কার্যকারিতা, নীতিগতভাবে, প্রত্যেকের জন্য উপযুক্ত।

সময় অতিবাহিত হওয়ার সাথে সাথে সবকিছুই কমবেশি স্থিরভাবে কাজ করে। কিন্তু তারপরে ইউরোপ রাশিয়ার বিরুদ্ধে নিষেধাজ্ঞা আরোপ করেছিল, যার ফলস্বরূপ রাশিয়ানরা মূলত অভ্যন্তরীণভাবে উত্পাদিত পণ্য কিনতে শুরু করেছিল এবং এই সংস্থার ব্যবসায় তীব্রভাবে চড়াও হয়েছিল। ব্যবহারকারীর সংখ্যা 50-60 জনে বেড়েছে, একটি নতুন শাখা খোলা হয়েছে এবং সেই অনুযায়ী নথির প্রবাহ বৃদ্ধি পেয়েছে। এবং এখন বর্তমান সার্ভার আর তীব্রভাবে বর্ধিত লোডের সাথে মানিয়ে নিতে পারে না এবং 1C শুরু হয়েছিল, যেমন তারা বলে, "ধীরগতি" করতে। পিক আওয়ারের সময়, নথিগুলি কয়েক মিনিটের জন্য প্রক্রিয়া করা হয়েছিল, ব্লকিং ত্রুটি ঘটেছে, ফর্মগুলি খুলতে অনেক সময় লেগেছে এবং অন্যান্য সম্পর্কিত পরিষেবাগুলির পুরো তোড়া। স্থানীয় সিস্টেম অ্যাডমিনিস্ট্রেটর সমস্ত সমস্যা দূর করে বললেন, "এটি আপনার 1C, আপনি এটি বের করবেন।" আমরা বারবার সিস্টেমের পারফরম্যান্স অডিট পরিচালনার প্রস্তাব দিয়েছি, কিন্তু তা কখনই অডিটে আসেনি। ক্লায়েন্ট সহজভাবে সমস্যার সমাধান করার জন্য সুপারিশ চেয়েছিলেন।

ঠিক আছে, আমি বসেছিলাম এবং DBMS এর সাথে টার্মিনাল সার্ভার এবং অ্যাপ্লিকেশন সার্ভারের ভূমিকা আলাদা করার প্রয়োজনীয়তা সম্পর্কে একটি দীর্ঘ চিঠি লিখেছিলাম (যা নীতিগতভাবে, আমরা ইতিমধ্যে অনেকবার বলেছি)। আমি টার্মিনাল সার্ভারে DFSS সম্পর্কে লিখেছি, শেয়ার্ড মেমরি সম্পর্কে, প্রামাণিক উত্সগুলির লিঙ্ক সরবরাহ করেছি এবং এমনকি সরঞ্জামগুলির জন্য কিছু বিকল্পের পরামর্শও দিয়েছি। এই চিঠিটি কোম্পানির ক্ষমতায় থাকা ব্যক্তিদের কাছে পৌঁছেছে, "বাস্তবায়ন" রেজোলিউশন নিয়ে আইটি বিভাগে ফিরে গেছে এবং বরফটি সাধারণত ভেঙে গেছে।

কিছু সময় পরে, অ্যাডমিন আমাকে নতুন সার্ভারের আইপি ঠিকানা এবং লগইন শংসাপত্র পাঠায়। তিনি বলেছেন যে MS SQL এবং 1C সার্ভারের উপাদানগুলি সেখানে স্থাপন করা হয়েছে, এবং ডাটাবেসগুলি স্থানান্তর করা দরকার, তবে আপাতত শুধুমাত্র DBMS সার্ভারে, যেহেতু 1C কীগুলির সাথে কিছু সমস্যা দেখা দিয়েছে৷

আমি এসেছি, প্রকৃতপক্ষে, সমস্ত পরিষেবা চলমান ছিল, সার্ভারটি খুব শক্তিশালী ছিল না, কিন্তু ঠিক আছে, আমি মনে করি এটি কিছুই না করার চেয়ে ভাল। বর্তমান সার্ভারকে কোনোভাবে উপশম করার জন্য আমি আপাতত ডাটাবেসগুলি স্থানান্তর করব। আমি সম্মত সময়ে সমস্ত স্থানান্তর সম্পন্ন করেছি, কিন্তু পরিস্থিতি পরিবর্তন হয়নি - এখনও একই কর্মক্ষমতা সমস্যা। এটা অদ্ভুত, অবশ্যই, ভাল, আসুন 1C ক্লাস্টারে ডাটাবেসগুলি নিবন্ধন করি এবং আমরা দেখতে পাব।

বেশ কিছু দিন পার হয়ে গেল, চাবি হস্তান্তর হয়নি। আমি ভাবছি সমস্যাটা কী, সবকিছুই সহজ বলে মনে হচ্ছে - এটিকে একটি সার্ভার থেকে বের করে নিন, অন্যটিতে প্লাগ করুন, ড্রাইভারটি ইনস্টল করুন এবং আপনার কাজ শেষ। প্রশাসক পোর্ট ফরওয়ার্ডিং, একটি ভার্চুয়াল সার্ভার এবং আরও অনেক কিছু সম্পর্কে বিরক্তি এবং কিছু বলে প্রতিক্রিয়া জানায়৷

হুম... ভার্চুয়াল সার্ভার? মনে হচ্ছে এখানে কোনো ভার্চুয়ালাইজেশন হয়নি এবং কখনো হয়নি... আমার মনে আছে একটি 1C সার্ভার কী একটি ভার্চুয়াল মেশিনে একটি 2008C সার্ভার কী ফরোয়ার্ড করার অসম্ভবতা নিয়ে একটি মোটামুটি পরিচিত সমস্যা ছিল হাইপার-ভি XNUMX-এ। এবং এখানে আমার মধ্যে কিছু সন্দেহ তৈরি হতে শুরু করে...

আমি সার্ভার ম্যানেজার খুলি - ভূমিকা - একটি নতুন ভূমিকা হাজির হয়েছে - হাইপার-ভি। আমি হাইপার-ভি ম্যানেজারে যাই, একটি ভার্চুয়াল মেশিন দেখি, সংযোগ করি... এবং প্রকৃতপক্ষে... আমাদের নতুন ডাটাবেস সার্ভার...

তাতে কি? কর্তৃপক্ষের নির্দেশ ও আমার সুপারিশ বাস্তবায়ন করা হয়েছে, ভূমিকা আলাদা করা হয়েছে। টাস্ক বন্ধ করা যেতে পারে।

কিছু সময়ের পরে, এখন সঙ্কট ঘটেছে, নতুন শাখাটি বন্ধ করতে হয়েছিল, লোড হ্রাস পেয়েছে এবং সিস্টেমের কার্যকারিতা কমবেশি সহনীয় হয়ে উঠেছে।

ঠিক আছে, অবশ্যই, তারা ভার্চুয়াল মেশিনে সার্ভার কী ফরোয়ার্ড করতে পারেনি। ফলস্বরূপ, সবকিছু যেমন বাকি ছিল: একটি ফিজিক্যাল মেশিনে টার্মিনাল সার্ভার + 1C ক্লাস্টার, ভার্চুয়ালে ডাটাবেস সার্ভার।

এবং এটি ভাল হবে যদি এটি কোনও ধরণের শারশকিনের অফিস হয়। তাই না. একটি সুপরিচিত কোম্পানি যার পণ্যগুলি আপনি সম্ভবত জানেন এবং সমস্ত লেন্টাস এবং আউচানের প্রাসঙ্গিক বিভাগে দেখেছেন।

হার্ড ড্রাইভ ছুটির সময়সূচী

বিশ্ব দখলের উচ্চাভিলাষী পরিকল্পনা নিয়ে একটি বড় হোল্ডিং কোম্পানি আবারও একটি ছোট কোম্পানিকে তার মেগা-কর্পোরেশনে অন্তর্ভুক্ত করার লক্ষ্য নিয়ে কিনেছে। এই হোল্ডিংয়ের সমস্ত বিভাগে, ব্যবহারকারীরা তাদের নিজস্ব ডাটাবেসে কাজ করে, কিন্তু একটি অভিন্ন কনফিগারেশনের সাথে। এবং তাই আমরা এই সিস্টেমে একটি নতুন ইউনিট অন্তর্ভুক্ত করার জন্য একটি ছোট প্রকল্প শুরু করেছি।

প্রথমত, উত্পাদন এবং পরীক্ষা ডাটাবেস স্থাপন করা প্রয়োজন। বিকাশকারী সংযোগ ডেটা পেয়েছে, সার্ভারে লগ ইন করেছে, MS SQL ইনস্টল করেছে, 1C সার্ভার দেখেছে, 2টি লজিক্যাল ড্রাইভ দেখেছে: 250 গিগাবাইট ক্ষমতার ড্রাইভ "C" এবং 1 টেরাবাইটের ক্ষমতা সহ "D" ড্রাইভ। ঠিক আছে, "C" হল সিস্টেম, "D" হল ডেটার জন্য, ডেভেলপার যৌক্তিকভাবে সিদ্ধান্ত নেয় এবং সেখানে সমস্ত ডেটাবেস স্থাপন করে। আমি এমনকি ব্যাকআপ সহ রক্ষণাবেক্ষণ পরিকল্পনাও সেট আপ করি, ঠিক সেই ক্ষেত্রে (যদিও আমরা এর জন্য দায়ী নই)। সত্য, ব্যাকআপ এখানে "D" তে যোগ করা হয়েছে। ভবিষ্যতে, এটিকে কিছু পৃথক নেটওয়ার্ক সংস্থানে পুনরায় কনফিগার করার পরিকল্পনা করা হয়েছিল।

প্রকল্প শুরু হয়, পরামর্শদাতারা কীভাবে নতুন সিস্টেমে কাজ করতে হয় সে সম্পর্কে প্রশিক্ষণ প্রদান করে, অবশিষ্টাংশ স্থানান্তরিত করা হয়, কিছু ছোটখাটো উন্নতি করা হয় এবং ব্যবহারকারীরা নতুন তথ্য বেসে কাজ শুরু করে।

সোমবার সকাল পর্যন্ত সবকিছু ঠিকঠাক চলছিল যখন এটি আবিষ্কার করা হয়েছিল যে ডাটাবেস ডিস্কটি নেই। সার্ভারে কেবল "ডি" নেই এবং এটিই।

আরও তদন্তে এটি প্রকাশিত হয়েছে: এই "সার্ভার" আসলে একটি স্থানীয় সিস্টেম প্রশাসকের কাজের কম্পিউটার ছিল। সত্য, এটিতে এখনও একটি সার্ভার ওএস ছিল। এই প্রশাসকের ব্যক্তিগত USB ড্রাইভ সার্ভারে প্লাগ করা হয়েছে৷ এবং তাই প্রশাসক ছুটিতে গিয়েছিলেন, তার সাথে তার স্ক্রু নিয়ে, ভ্রমণের জন্য এটিতে সিনেমা পাম্প করার লক্ষ্য নিয়ে।

ঈশ্বরকে ধন্যবাদ, তিনি ডাটাবেস ফাইলগুলি মুছে ফেলতে পারেননি এবং উত্পাদনশীল ডাটাবেস পুনরুদ্ধার করতে সক্ষম হন।

এটি লক্ষণীয় যে প্রত্যেকে সাধারণত একটি USB ড্রাইভে অবস্থিত সিস্টেমের কার্যকারিতা নিয়ে সন্তুষ্ট ছিল। 1C-এর অসন্তোষজনক পারফরম্যান্স সম্পর্কে কেউ অভিযোগ করেনি। এটি কেবল পরেই যে হোল্ডিংটি সুপার-সার্ভার সহ একটি একক কেন্দ্রীভূত সাইটে সমস্ত তথ্য ডাটাবেস স্থানান্তর করার জন্য একটি মেগা-প্রকল্প শুরু করে, এক মিলিয়ন+ রুবেলের স্টোরেজ সিস্টেম, অত্যাধুনিক হাইপারভাইজার এবং সমস্ত শাখায় অসহনীয় 1C ব্রেক।

কিন্তু এটা সম্পূর্ণ ভিন্ন গল্প...

উত্স: www.habr.com