90% অবজেক্ট স্টোরেজে ব্যাকআপের সঞ্চয়স্থান কীভাবে কমপ্যাক্ট করবেন

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

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

কাজ: সবকিছু তৈরি করা যাতে ব্যাকআপ কপি সংরক্ষণের প্রক্রিয়া দ্রুত এবং সস্তা হয়।

প্রকৃতপক্ষে, এর আগে, এস 3-এর সমস্ত কিছুই ছিল কেবল ফাইল, এবং এগুলি ডেটা সেন্টারের সমালোচনামূলক মেশিনগুলির সম্পূর্ণ কাস্ট ছিল। অর্থাৎ, এটি খুব অপ্টিমাইজ করা হয়নি, তবে শুরুতে সবকিছুই কাজ করেছে। এখন এটি খুঁজে বের করার এবং এটি সঠিক করার সময়।

ছবিটি দেখায় যে আমরা কী এসেছি:

আপনি দেখতে পাচ্ছেন, প্রথম ব্যাকআপ ধীরে ধীরে তৈরি করা হয়েছিল (70 Mb/s), এবং একই সিস্টেমের পরবর্তী ব্যাকআপগুলি অনেক দ্রুত ছিল।

প্রকৃতপক্ষে, সেখানে কী কী বৈশিষ্ট্য রয়েছে সে সম্পর্কে আরও কিছু বিবরণ রয়েছে।

যারা ডাম্পের অর্ধেক পৃষ্ঠা পড়তে প্রস্তুত তাদের জন্য ব্যাকআপ লগরিস্ক্যান সহ পূর্ণ
18 ডিসেম্বর, 2018 12:09:43 PM — তথ্য bpbkar (pid=4452) অ্যাক্সিলারেটর সার্ভারে 14883996160 বাইটের মধ্যে 14883994624 বাইট পাঠিয়েছে, অপ্টিমাইজেশান 0.0%
18 ডিসেম্বর, 2018 12:10:07 PM - তথ্য NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; রিপোর্ট=PDDO পরিসংখ্যান (মাল্টি-থ্রেডেড স্ট্রীম ব্যবহৃত) এর জন্য (NBCC): স্ক্যান করা হয়েছে: 14570817 KB, CR পাঠানো হয়েছে: 1760761 KB, CR পাঠানো হয়েছে FC: 0 KB, ডিডআপ: 87.9%, ক্যাশে অক্ষম

পূর্ণ
18 ডিসেম্বর, 2018 12:13:18 PM — তথ্য bpbkar (pid=2864) অ্যাক্সিলারেটর সার্ভারে 181675008 বাইটের মধ্যে 14884060160 বাইট পাঠিয়েছে, অপ্টিমাইজেশান 98.8%
18 ডিসেম্বর, 2018 12:13:40 PM - তথ্য NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; রিপোর্ট=PDDO পরিসংখ্যান (NBCC): স্ক্যান করা হয়েছে: 14569706 KB, CR পাঠানো হয়েছে: 45145 KB, CR পাঠানো হয়েছে FC: 0 KB, ডিডআপ: 99.7%, ক্যাশে অক্ষম

ক্রমবর্ধমান
18 ডিসেম্বর, 2018 12:15:32 PM — তথ্য bpbkar (pid=792) অ্যাক্সিলারেটর সার্ভারে 9970688 বাইটের মধ্যে 14726108160 বাইট পাঠিয়েছে, অপ্টিমাইজেশান 99.9%
18 ডিসেম্বর, 2018 12:15:53 PM - তথ্য NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; রিপোর্ট=PDDO পরিসংখ্যান (NBCC): স্ক্যান করা হয়েছে: 14383788 KB, CR পাঠানো হয়েছে: 15700 KB, CR পাঠানো হয়েছে FC: 0 KB, ডিডআপ: 99.9%, ক্যাশে অক্ষম

পূর্ণ
18 ডিসেম্বর, 2018 12:18:02 PM — তথ্য bpbkar (pid=3496) অ্যাক্সিলারেটর সার্ভারে 171746816 বাইটের মধ্যে 14884093952 বাইট পাঠিয়েছে, অপ্টিমাইজেশান 98.8%
18 ডিসেম্বর, 2018 12:18:24 PM - তথ্য NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; রিপোর্ট=PDDO পরিসংখ্যান (NBCC): স্ক্যান করা হয়েছে: 14569739 KB, CR পাঠানো হয়েছে: 34120 KB, CR পাঠানো হয়েছে FC: 0 KB, ডিডআপ: 99.8%, ক্যাশে অক্ষম

সমস্যাটা কি

গ্রাহকরা যতবার সম্ভব ব্যাকআপ করতে চান এবং যতটা সম্ভব সস্তায় সঞ্চয় করতে চান। S3-এর মতো অবজেক্ট স্টোরেজে এগুলি সস্তায় সঞ্চয় করা ভাল, কারণ প্রতি মেগাবাইট পরিষেবার মূল্যে এগুলি সবচেয়ে সস্তা যেখান থেকে আপনি যুক্তিসঙ্গত সময়ে ব্যাকআপ ব্যাক করতে পারেন৷ যখন প্রচুর ব্যাকআপ থাকে, তখন এটি খুব সস্তা হয় না, কারণ বেশিরভাগ স্টোরেজ একই ডেটার অনুলিপি দ্বারা দখল করা হয়। তুর্কি সহকর্মীদের HaaS এর ক্ষেত্রে, স্টোরেজ প্রায় 80-90% দ্বারা ঘনীভূত করা যেতে পারে। এটা স্পষ্ট যে এটি তাদের নির্দিষ্টতার সাথে বিশেষভাবে সম্পর্কিত, তবে আমি অবশ্যই কমপক্ষে 50% দাদার উপর নির্ভর করব।

সমস্যা সমাধানের জন্য, প্রধান বিক্রেতারা অ্যামাজন এস 3 এর গেটওয়ে তৈরি করেছে। তাদের সমস্ত পদ্ধতি স্থানীয় S3 এর সাথে সামঞ্জস্যপূর্ণ যতক্ষণ তারা Amazon API সমর্থন করে। তুর্কি ডেটা সেন্টারে, আমাদের S3-তে ব্যাকআপ নেওয়া হয়, সেইসাথে রাশিয়ার T-III "কম্প্রেসর"-এ, যেহেতু এই কাজের স্কিমটি আমাদের জন্য ভাল কাজ করেছে।

এবং আমাদের S3 সম্পূর্ণরূপে Amazon S3 ব্যাকআপ পদ্ধতির সাথে সামঞ্জস্যপূর্ণ। অর্থাৎ, এই পদ্ধতিগুলিকে সমর্থন করে এমন সমস্ত ব্যাকআপ সরঞ্জামগুলি আপনাকে "বাক্সের বাইরে" এই ধরনের স্টোরেজে সবকিছু অনুলিপি করতে দেয়।

Veritas NetBackup CloudCatalyst বৈশিষ্ট্য যোগ করেছে:

অর্থাৎ, যে মেশিনগুলির ব্যাক আপ নেওয়া দরকার এবং গেটওয়ের মধ্যে, একটি মধ্যবর্তী লিনাক্স সার্ভার রয়েছে যার মাধ্যমে SRK এজেন্টদের থেকে ব্যাকআপ ট্র্যাফিক চলে যায় এবং S3 এ স্থানান্তর করার আগে ফ্লাইতে ডিডুপ্লিকেট করা হয়। যদি আগে কম্প্রেশন সহ 30 গিগাবাইটের 20 টি ব্যাকআপ থাকত, এখন (মেশিনের মিলের কারণে) তাদের ভলিউম 90% ছোট হয়ে গেছে। ডিডুপ্লিকেশন ইঞ্জিনটি নেটব্যাকআপ ব্যবহার করে নিয়মিত ডিস্কে সংরক্ষণ করার সময় একইভাবে ব্যবহৃত হয়।

মধ্যবর্তী সার্ভারের আগে যা ঘটে তা এখানে:

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

লগ228টি চাকরি (0 সারিবদ্ধ 0 সক্রিয় 0 পুনঃপ্রচেষ্টার জন্য অপেক্ষা করা হচ্ছে 0 স্থগিত 0 অসম্পূর্ণ 228 সম্পন্ন হয়েছে — 13টি নির্বাচিত)
(ফিল্টার প্রয়োগ করা হয়েছে [13])

কাজের আইডির ধরন রাজ্যের বিশদ বিবরণ স্থিতি চাকরির নীতি কাজের সময়সূচী ক্লায়েন্ট মিডিয়া সার্ভার শুরুর সময় অতিবাহিত শেষ সময় সঞ্চয়স্থান ইউনিট প্রচেষ্টা অপারেশন কিলোবাইট ফাইল পাথনাম % সম্পূর্ণ (আনুমানিক) চাকরির পিআইডি মালিক কপি পিতামাতার চাকরির আইডি KB/সেকেন্ড সক্রিয় স্টার্ট স্টার্ট অ্যাক্টিভ রোবট অ্যাক্টিভ ভ্যাপস ডেটা মুভমেন্ট অফ-হোস্ট টাইপ মাস্টার প্রায়োরিটি ডিডুপ্লিকেশন রেট ট্রান্সপোর্ট অ্যাক্সিলারেটর অপ্টিমাইজেশন ইনস্ট্যান্স বা ডেটাবেস শেয়ার হোস্টের জন্য আইডি মিডিয়া
— 1358 স্ন্যাপশট সম্পন্ন হয়েছে 0 VMware — NGNCloudADC NBCC ডিসেম্বর 18, 2018 12:16:19 PM 00:02:18 18 ডিসেম্বর, 2018 12:18:37 PM STU_DP_S3_****ব্যাকআপ 1 100% রুট 1358 :18:2018 PM 12:16:27 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 00
1360 ব্যাকআপ সম্পন্ন হয়েছে 0 VMware সম্পূর্ণ NGNCloudADC NBCC 18 ডিসেম্বর, 2018 12:16:48 PM 00:01:39 ডিসেম্বর 18, 2018 12:18:27 PM STU_DP_S3_**ব্যাকআপ 1 14,535,248%149654 100 23858 ডিসেম্বর 1358 , 335,098 18:2018:12 PM 16:48:00 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 01 39% 0%
1352 স্ন্যাপশট সম্পন্ন হয়েছে 0 VMware - NGNCloudADC NBCC ডিসেম্বর 18, 2018 12:14:04 PM 00:02:01 ডিসেম্বর 18, 2018 12:16:05 PM STU_DP_S3_****ব্যাকআপ 1 ডিসে 100, 1352% ব্যাকআপ 18:2018 PM 12:14:14 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 00
1354 ব্যাকআপ সম্পন্ন হয়েছে 0 VMware ইনক্রিমেন্টাল NGNCloudADC NBCC 18 ডিসেম্বর, 2018 12:14:34 PM 00:01:21 ডিসেম্বর 18, 2018 12:15:55 PM STU_DP_S3_**ব্যাকআপ 1%, 14,380,965 147 100 ডিসেম্বর 23617 , 1352 500,817:18:2018 PM 12:14:34 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-************ 00 01% 21%
1347 স্ন্যাপশট সম্পন্ন হয়েছে 0 VMware - NGNCloudADC NBCC ডিসেম্বর 18, 2018 12:11:45 PM 00:02:08 ডিসেম্বর 18, 2018 12:13:53 PM STU_DP_S3_****ব্যাকআপ 1 ডিসে 100, 1347% ব্যাকআপ 18:2018 PM 12:11:45 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 00
1349 ব্যাকআপ সম্পন্ন হয়েছে 0 VMware সম্পূর্ণ NGNCloudADC NBCC 18 ডিসেম্বর, 2018 12:12:02 PM 00:01:41 ডিসেম্বর 18, 2018 12:13:43 PM STU_DP_S3_**ব্যাকআপ 1 14,535,215%149653 100 23508 ডিসেম্বর 1347 , 316,319 18:2018:12 PM 12:02:00 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 01 41% 0%
1341 স্ন্যাপশট সম্পন্ন হয়েছে 0 VMware - NGNCloudADC NBCC ডিসেম্বর 18, 2018 12:05:28 PM 00:04:53 ডিসেম্বর 18, 2018 12:10:21 PM STU_DP_S3_****ব্যাকআপ 1 ডিসে 100, 1341% ব্যাকআপ 18:2018 PM 12:05:28 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 00
1342 ব্যাকআপ সম্পন্ন হয়েছে 0 VMware Full_Rescan NGNCloudADC NBCC 18 ডিসেম্বর, 2018 12:05:47 PM 00:04:24 ডিসেম্বর 18, 2018 12:10:11 PM STU_DP_S3_**ব্যাকআপ, 1% 14,535,151 149653 root 100 22999 1341 Dec 70,380 , 18 2018:12:05 PM 47:00:04 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-************ 24 0% 87.9%

1339 স্ন্যাপশট সম্পন্ন হয়েছে 150 VMware - NGNCloudADC NBCC ডিসেম্বর 18, 2018 11:05:46 AM 00:00:53 18 ডিসেম্বর, 2018 11:06:39 AM STU_DP_S3_**ব্যাকআপ %1% ব্যাকআপ 100 1339:18 AM 2018:11:05 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 46
1327 স্ন্যাপশট সম্পন্ন 0 VMware - *******।********।ক্লাউড NBCC ডিসেম্বর 17, 2018 12:54:42 PM 05:51:38 ডিসেম্বর 17, 2018 6:46:20 PM STU_DP_S3_****ব্যাকআপ 1 100% রুট 1327 ডিসেম্বর 17, 2018 12:54:42 PM 05:51:38 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 0
1328 ব্যাকআপ সম্পন্ন 0 VMware সম্পূর্ণ *******।********।ক্লাউড NBCC ডিসেম্বর 17, 2018 12:55:10 PM 05:29:21 ডিসেম্বর 17, 2018 6:24:31 PM STU_DP_S3_****ব্যাকআপ 1 222,602,719 258932 100% 12856 রুট 1327 11,326 ডিসেম্বর 17, 2018 12:55:10 অপরাহ্ণ 05:29:21 ইনস্ট্যান্ট রিকভারি ডিস্ক **0%*** INস্ট্যান্ট রিকভারি ডিস্ক**** INSTANT রিকভারি ডিস্ক****87.9%**** 0%
1136 স্ন্যাপশট সম্পন্ন 0 VMware - *******।********।ক্লাউড NBCC ডিসেম্বর 14, 2018 4:48:22 PM 04:05:16 ডিসেম্বর 14, 2018 8:53:38 PM STU_DP_S3_****ব্যাকআপ 1 100% রুট 1136 ডিসেম্বর 14, 2018 4:48:22 PM 04:05:16 ইনস্ট্যান্ট রিকভারি ডিস্ক স্ট্যান্ডার্ড WIN-*********** 0
1140 ব্যাকআপ সম্পন্ন হয়েছে 0 VMware Full_Scan *******।********।ক্লাউড NBCC ডিসেম্বর 14, 2018 4:49:14 PM 03:49:58 ডিসেম্বর 14, 2018 8:39:12 PM STU_DP_S3_****ব্যাকআপ 1 217,631,332 255465 100% 26438 রুট 1136 15,963 ডিসে 14, 2018 4:49:14 PM 03:49:58 তাত্ক্ষণিক পুনরুদ্ধার ডিস্ক*** IN0% ** INস্ট্যান্ট রিকভারি ডিস্ক**** IN45.2% ** 0 স্ট্যান্ডার্ড XNUMX%

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

মধ্যবর্তী সার্ভারের নিজস্ব সঞ্চয়স্থান রয়েছে, যেখানে এটি ডেটার একটি "ক্যাশে" লিখে এবং ডিডপ্লিকেশনের জন্য একটি ডাটাবেস বজায় রাখে।

সম্পূর্ণ আর্কিটেকচার এই মত দেখায়:

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

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

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

পুনরুদ্ধার করার সময়, মিডিয়া সার্ভার S3 থেকে প্রয়োজনীয় অনুলিপি করা বস্তুর অনুরোধ করে, সেগুলিকে রিহাইড্রেট করে এবং IRB এজেন্টদের কাছে স্থানান্তর করে, যেমন পুনরুদ্ধারের সময় ট্র্যাফিকের পরিমাণ বিবেচনা করা প্রয়োজন, যা পুনরুদ্ধার করা ডেটার প্রকৃত পরিমাণের সমান হবে।

এটি দেখে মনে হচ্ছে এখানে:

এবং এখানে লগ আরেকটি টুকরা169টি চাকরি (0 সারিবদ্ধ 0 সক্রিয় 0 পুনঃপ্রচেষ্টার জন্য অপেক্ষা করা হচ্ছে 0 স্থগিত 0 অসম্পূর্ণ 169 সম্পন্ন হয়েছে — 1টি নির্বাচিত)

কাজের আইডির ধরন রাজ্যের বিশদ বিবরণ স্থিতি চাকরির নীতি কাজের সময়সূচী ক্লায়েন্ট মিডিয়া সার্ভার শুরুর সময় অতিবাহিত শেষ সময় সঞ্চয়স্থান ইউনিট প্রচেষ্টা অপারেশন কিলোবাইট ফাইল পাথনাম % সম্পূর্ণ (আনুমানিক) চাকরির পিআইডি মালিক কপি পিতামাতার চাকরির আইডি KB/সেকেন্ড সক্রিয় স্টার্ট স্টার্ট অ্যাক্টিভ রোবট অ্যাক্টিভ ভ্যাপস ডেটা মুভমেন্ট অফ-হোস্ট টাইপ মাস্টার প্রায়োরিটি ডিডুপ্লিকেশন রেট ট্রান্সপোর্ট অ্যাক্সিলারেটর অপ্টিমাইজেশন ইনস্ট্যান্স বা ডেটাবেস শেয়ার হোস্টের জন্য আইডি মিডিয়া
- 1372 পুনরুদ্ধার করা হয়েছে 0 NBPR01 NBCC ডিসেম্বর 19, 2018 1:05:58 PM 00:04:32 ডিসেম্বর 19, 2018 1:10:30 PM 1 14,380,577 1 100% OT 8548 1372 70,567% OT 19. 2018 1:06 :00 PM 00:04:30 WIN-*********** 90000

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

মিডিয়া সার্ভারের 4 TB ক্যাশে প্রয়োজন - এটি ভেরিটাসের ন্যূনতম আকারের সুপারিশ। আরও ভাল, কিন্তু আমরা কি করেছি।

ফলাফল

Когда партнёр кидал в наше S3 20 Гб, мы хранили 60 Гб, потому что обеспечиваем трёхкратное георезервирование данных. Сейчас трафика куда меньше, что хорошо и для канала, и для тарификации по хранению.

এই ক্ষেত্রে, রুটগুলি "বড় ইন্টারনেট" এর পরে বন্ধ রয়েছে, তবে আপনি ইন্টারনেটের মাধ্যমে VPN L2 এর মাধ্যমে ট্র্যাফিক চালাতে পারেন, তবে সরবরাহকারীর প্রবেশের আগে মিডিয়া সার্ভারটি ইনস্টল করা ভাল।

আপনি যদি আমাদের রাশিয়ান ডেটা সেন্টারে এই বৈশিষ্ট্যগুলি সম্পর্কে জানতে আগ্রহী হন বা বাড়িতে বাস্তবায়ন সম্পর্কে প্রশ্ন থাকে তবে মন্তব্যে বা ইমেলের মাধ্যমে জিজ্ঞাসা করুন [ইমেল সুরক্ষিত].

উত্স: www.habr.com