সাইবারপাঙ্কের স্বাদে একটি ক্লাউড পরিষেবা তৈরির ইতিহাস

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

তাই আমরা একটি ক্লাউড প্ল্যাটফর্ম তৈরি করার সম্মান পেয়েছি, এবং এর জন্য আমাদের সাথে কাজ করার জন্য কয়েকটি সাবসিস্টেমকে "প্ররোচিত" করতে হবে। সৌভাগ্যবশত, আমাদের একটি "API ভাষা", সরাসরি হাত এবং প্রচুর উৎসাহ রয়েছে৷

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

বিড়াল স্বাগতম.

যাত্রা শুরু

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

এছাড়াও বেশ কয়েকটি প্রয়োজনীয়তা ছিল:

• পরিষেবাটির জন্য একটি সুবিধাজনক ব্যক্তিগত অ্যাকাউন্ট প্রয়োজন;
• প্ল্যাটফর্মটি বিদ্যমান বিলিং সিস্টেমের সাথে একত্রিত করা আবশ্যক;
• সফ্টওয়্যার এবং হার্ডওয়্যার: OpenStack + Tungsten Fabric (Open Contrail), যা আমাদের প্রকৌশলীরা বেশ ভালোভাবে "রান্না" করতে শিখেছেন।

হাবরা সম্প্রদায় আগ্রহী হলে দলটি কীভাবে একত্রিত হয়েছিল, ব্যক্তিগত অ্যাকাউন্ট ইন্টারফেস তৈরি করা হয়েছিল এবং ডিজাইনের সিদ্ধান্ত নেওয়া হয়েছিল সে সম্পর্কে আমরা আপনাকে অন্য সময় বলব।
আমরা যে সরঞ্জামগুলি ব্যবহার করার সিদ্ধান্ত নিয়েছি:

• Python + Flask + Swagger + SQLAlchemy - একটি সম্পূর্ণ আদর্শ পাইথন সেট;
• ফ্রন্টএন্ডের জন্য Vue.js;
• আমরা AMQP এর উপর সেলারি ব্যবহার করে উপাদান এবং পরিষেবাগুলির মধ্যে মিথস্ক্রিয়া করার সিদ্ধান্ত নিয়েছি।

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

সুতরাং, আসুন আমাদের পরিচিতি শুরু করা যাক।

নীরব বিল - বিলিং

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

বিলিং হল প্রথম সিস্টেম যার সাথে আমরা বন্ধুত্ব করার চেষ্টা করেছি৷ এবং পরিষেবাগুলি প্রক্রিয়াকরণের সময় আমরা প্রথম অসুবিধার সম্মুখীন হয়েছিলাম৷

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

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

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

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

আরেকটি সমস্যা হল নীরবতা।

বিলি নীরবে কিছু API অনুরোধের "ঠিক আছে" উত্তর দেয়। এই ঘটনাটি ছিল, উদাহরণস্বরূপ, যখন আমরা পরীক্ষার সময় প্রতিশ্রুত অর্থপ্রদানের অর্থ প্রদান করেছি (পরে আরও বেশি)। অনুরোধগুলি সঠিকভাবে সম্পাদিত হয়েছে এবং আমরা কোনো ত্রুটি দেখিনি৷

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

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

সুতরাং, সংক্ষেপে বলতে গেলে, মিথস্ক্রিয়া পর্যায়ে আমরা যে প্রধান সমস্যাগুলির সম্মুখীন হয়েছি তা একটি নির্দিষ্ট সিস্টেমের বাস্তবায়ন বৈশিষ্ট্যগুলির সাথে সম্পর্কিত:

• দলিলবিহীন "বৈশিষ্ট্য" যা আমাদেরকে কোনো না কোনোভাবে প্রভাবিত করেছে;
• ক্লোজড সোর্স (বিলিং C++ এ লেখা হয়), ফলস্বরূপ - "ট্রায়াল এবং এরর" ছাড়া অন্য কোনো উপায়ে সমস্যা 1 সমাধান করা অসম্ভব।

ভাগ্যক্রমে, পণ্যটির একটি মোটামুটি বিস্তৃত API রয়েছে এবং আমরা আমাদের ব্যক্তিগত অ্যাকাউন্টে নিম্নলিখিত সাবসিস্টেমগুলিকে একীভূত করেছি:

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

টাংস্টেন ক্ষেত্রগুলির মধ্য দিয়ে হাঁটা - টুংস্টেন ফ্যাব্রিক

টংস্টেন ক্ষেত্রগুলি শত শত তারের সাথে বিন্দুযুক্ত, তাদের মাধ্যমে হাজার হাজার বিট তথ্য পাস করে। তথ্য সংগ্রহ করা হয় “প্যাকেট”-এ, পার্স করা, জটিল রুট তৈরি করা, যেন জাদু দ্বারা।

এটি দ্বিতীয় সিস্টেমের ডোমেন যার সাথে আমাদের বন্ধুত্ব করতে হয়েছিল - Tungsten Fabric (TF), পূর্বে OpenContrail। এর কাজ হল নেটওয়ার্ক সরঞ্জাম পরিচালনা করা, ব্যবহারকারী হিসাবে আমাদের কাছে একটি সফ্টওয়্যার বিমূর্ততা প্রদান করা। TF - SDN, নেটওয়ার্ক সরঞ্জামগুলির সাথে কাজ করার জটিল যুক্তিকে অন্তর্ভুক্ত করে। প্রযুক্তি নিজেই সম্পর্কে একটি ভাল নিবন্ধ আছে, উদাহরণস্বরূপ, এখানে.

সিস্টেমটি নিউট্রন প্লাগইনের মাধ্যমে OpenStack (নীচে আলোচনা করা হয়েছে) সাথে একত্রিত করা হয়েছে।

OpenStack পরিষেবার মিথস্ক্রিয়া।

অপারেশন বিভাগের ছেলেরা আমাদের এই সিস্টেমের সাথে পরিচয় করিয়ে দেয়। আমরা আমাদের পরিষেবাগুলির নেটওয়ার্ক স্ট্যাক পরিচালনা করতে সিস্টেমের API ব্যবহার করি। এটি এখনও আমাদের কোনও গুরুতর সমস্যা বা অসুবিধার কারণ হয়নি (আমি OE থেকে ছেলেদের জন্য কথা বলতে পারি না), তবে মিথস্ক্রিয়ায় কিছু অদ্ভুততা রয়েছে।

প্রথমটি এইরকম দেখায়: যে কমান্ডগুলি SSH এর মাধ্যমে সংযোগ করার সময় ইনস্ট্যান্স কনসোলে প্রচুর পরিমাণে ডেটা আউটপুট করার প্রয়োজন হয়, সংযোগটি কেবল "হ্যাং আপ" করে, যখন VNC এর মাধ্যমে সবকিছু সঠিকভাবে কাজ করে।

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

পরবর্তী সমস্যা ঠিক কোণার কাছাকাছি ছিল. এক "সুন্দর" মুহুর্তে, রাউটিংয়ের যাদুটি অদৃশ্য হয়ে গেল, ঠিক তেমনই। TF সরঞ্জামগুলিতে রাউটিং পরিচালনা করা বন্ধ করেছে৷

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

সিলিকন লাইফফর্মস - ওপেনস্ট্যাক

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

OpenStack আমাদের প্ল্যাটফর্মের মূল।

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

প্রতিটি পরিষেবা একটি পাত্রে চলে, এবং বার্তা দালাল হল "সাদা খরগোশ" - RabbitMQ৷

এই সিস্টেমটি আমাদের সবচেয়ে অপ্রত্যাশিত সমস্যা দিয়েছে।

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

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

ডিস্কের সাথে কাজ করার সময় আরেকটি অসুবিধা আমাদের জন্য অপেক্ষা করছে। সিস্টেম ভলিউম সার্ভার থেকে সংযোগ বিচ্ছিন্ন করা যায়নি.

আবার, OpenStack নিজেই "শপথ করে" যে এটি সংযোগটি ধ্বংস করেছে এবং এখন আপনি সঠিকভাবে ভলিউম নিয়ে আলাদাভাবে কাজ করতে পারেন। কিন্তু API স্পষ্টতই ডিস্কে অপারেশন করতে চায়নি।

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

OpenStack হল একটি জটিল সিস্টেমের সেট যার নিজস্ব ইন্টারঅ্যাকশন লজিক এবং অলঙ্কৃত API। আমরা মোটামুটি বিস্তারিত ডকুমেন্টেশন এবং অবশ্যই, ট্রায়াল এবং ত্রুটি (এটি ছাড়া আমরা কোথায় থাকব) দ্বারা সাহায্য করা হয়।

টেস্ট রান

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

পরীক্ষা নিজেই, অবশ্যই, এর মজার মুহূর্তগুলি ছাড়া ছিল না, কারণ এখানেই আমাদের অ্যাডভেঞ্চারগুলি সবে শুরু হয়েছে।

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

আরেকটি কৌতূহল আপনার ব্যক্তিগত অ্যাকাউন্টে "পাসওয়ার্ড পরিবর্তন করুন" বোতামের কার্যকারিতার সাথে সম্পর্কিত।

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

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

এই সূক্ষ্মতা সত্ত্বেও, পরীক্ষা ভাল গিয়েছিল। কয়েক সপ্তাহের মধ্যে, প্রায় 300 লোক সেখানে থামে। আমরা ব্যবহারকারীদের চোখ দিয়ে পণ্যটি দেখতে সক্ষম হয়েছি, এটিকে কার্যকরভাবে পরীক্ষা করতে এবং উচ্চ-মানের প্রতিক্রিয়া সংগ্রহ করতে পেরেছি।

অবিরত করা

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

অবশ্যই, কোডের ক্ষেত্রে এবং সিস্টেম ইন্টিগ্রেশনের ইন্টারফেসে উভয় ক্ষেত্রেই কাজ করার কিছু আছে। প্রকল্পটি বেশ তরুণ, কিন্তু আমরা এটিকে একটি নির্ভরযোগ্য এবং সুবিধাজনক পরিষেবাতে পরিণত করার উচ্চাকাঙ্ক্ষায় পূর্ণ।

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

আমরা সম্প্রতি পরিষেবা চালু করেছি।
আপনি আমাদের সমস্ত বিবরণ জানতে পারেন ওয়েবসাইট.

CLO উন্নয়ন দল

দরকারী লিঙ্ক

OpenStack

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

টংস্টেন ফ্যাব্রিক

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

উত্স: www.habr.com