اوپنستک سویفت

اوپنستک سویفت (Openstack Swift) یک ذخیره‌ساز اشیاء متن‌باز نرم‌افزارمحور توزیع شده از نوع AP است، یعنی در صورت بروز خطا و یا قطعی جزئی در شبکه، همچنان کاربران به حداقل یک کپی از داده خود دسترسی دارند و از لحاظ یکپارچگی داده، سازگاری نهایی دارد. یعنی اگر بروزرسانی جدیدی بروی یک داده انجام نشود، در نهایت تمامی درخواست‌های خواندن آن داده، آخرین مقدار به روز شده را برمی‌گرداند.

ذخیره‌سازی نرم‌افزارمحور (SDS) به کاربران و سازمان‌ها این امکان را می‌دهد که منابع ذخیره‌سازی خود را از لایه سخت‌افزاری زیرین برای انعطاف‌پذیری، کارایی بیشتر و مقیاس‌پذیری سریعتر، جدا یا انتزاعی کنند. سازمان‌ها می‌توانند از سویفت برای ذخیره داده‌ بسیار به صورت کارآمد، ایمن و ارزان استفاده کنند.

ذخیره‌سازی اشیاء سیستمی است که، داده را به صورت واحدهای جداگانه و مستقل در یک محیط مسطح، همه اشیاء در یک سطح، ذخیره می‌کند. هیچ پوشه یا زیرپوشه‌ای به معنای پوشه‌ در ذخیره‌سازی فایل، وجود ندارد. به‌علاوه، ذخیره‌سازی اشیاء الزاما همه داده‌ را با هم در یک فایل ذخیره نمی‌کند.

اشیاء همچنین حاوی فراداده هستند، که اطلاعاتی در مورد فایل است که به پردازش و استفاده از آن کمک می‌کند. کاربران می‌توانند مقدار فراداده‌های سیستمی را در هنگام یا بعد از ذخیره‌سازی شی تعیین کنند، یا می‌توانند فراداده سفارشی مرتبط با یک شی را با تعیین کلید و مقدار آن، ایجاد کنند.

به جای استفاده از نام فایل و مسیر برای دسترسی به یک شی، هر شی یک شناسه منحصر به فرد دارد. اشیاء را می توان به صورت محلی در هارد دیسک‌های کامپیوتر و یا سرورهای ابری ذخیره کرد. با این حال، برخلاف ذخیره‌سازی فایل، برای دسترسی و مدیریت اشیاء باید از رابط برنامه‌نویسی کاربردی (API) استفاده کنید.

برای دسترسی به سویفت شما می‌توانید با پروتکل Swift یا S3 درخواست‌‌های HTTP را مستقیماً به API سویفت ارسال کنید و یا از یکی از بسیار کتابخانه‌‌ی سویفت در جاوا، پایتون، روبی و جاوا اسکریپت استفاده کنید. این مسئله آن را به عنوان یک سیستم ذخیره‌سازی اصلی برای ذخیره و دسترسی به داده‌ها از طریق کلاینت، دستگاه‌ها و برنامه‌های کاربردی تحت وب، ایده‌آل می‌سازد.

به گفته شرکت تحلیلگر صنعت گارتنر، سویفت پرکاربردترین پروژه OpenStack است، زیرا معمولاً با سایر چارچوب‌های رایانش ابری و یا به عنوان یک سیستم ذخیره‌سازی مستقل استفاده می‌شود. طراحی انعطاف‌پذیر سویفت همچنین آن را قادر می‌سازد تا با سیستم‌های احراز هویت سازمانی و ابزارهای مدیریت فناوری اطلاعات یکپارچه شود. انعکاس استقبال روزافزون استفاده از سویفت را می‌توان در پشتیانی از API سویفت در تعداد زیادی از محبوب‌ترین برنامه‌های پشتیبان‌گیری و مدیریت محتوا مشاهده کرد.

خلاصه ای از ویژگی‌های سویفت در ادامه اشاره شده است:

• سویفت بخشی از پروژه OpenStack است و به صورت متن‌باز و رایگان در دسترس است.
• سویفت می تواند به عنوان یک سیستم ذخیره‌ساز مستقل یا به عنوان بخشی از یک محیط رایانش ابری مورد استفاده قرار بگیرد.
• سویفت روی توزیع‌های استاندارد لینوکس و روی سخت‌افزار استاندارد سرورهای x86 اجرا می‌شود.
• سوئیفت مانند آمازون S3 دارای یک معماری با سازگاری نهایی است که آن را برای پیاده‌سازی زیرساخت‌های عظیم و پراکنده از نظر جغرافیایی با تعداد زیادی داده بدون ساختار ایده‌آل می‌کند.
• همه اشیاء با چندین کپی ذخیره می‌شوند و در مناطق و/یا نواحی در دسترس منحصر به فرد، تکرار می‌شوند.
• سویفت با افزودن سرور‌های اضافی، مقیاس‌بندی می‌شود که امکان گسترش فضای ذخیره‌سازی خطی مقرون‌به‌صرفه را فراهم می‌کند.
• هنگام افزودن یا جایگزینی سخت‌افزار، داده‌ها لزومی ندارد به یک سیستم ذخیره‌سازی جدید منتقل شوند. سرورها و دیسک‌های مشکل‌دار و خراب را می توان در حالی که کلاستر در حال اجراست بدون خللی در سرویس‌دهی تعویض کرد. سرورها و دیسک‌های جدید را نیز می‌توان به همین شکل اضافه کرد.
• تمام اشیاء (داده) ذخیره شده در سویفت دارای یک URL و شناسه واحد هستند.
• برنامه‌های کاربردی، داده‌ها را در سویفت از طریق یک API استاندارد صنعتی RESTful ذخیره و بازیابی می‌کنند.
• اشیا می‌توانند فراداده (متادیتا) گسترده‌ای داشته باشند که می توان آنها را فهرست‌بندی و سپس جستجو کرد.
• سویفت در حال حاضر بزرگترین ذخیره‌سازهای اشیاء ابری، از جمله Rackspace Cloud Files، HP Cloud، IBM Softlayer Cloudو تعداد بی شماری کلاستر‌های ذخیره‌سازی اشیاء خصوصی دیگر (SwiftStack) را تامین می کند.

معماری سویفت

سویفت مجموعه‌­ای از سرور یا ماشین‌­ها است که سرویس‌­های اصلی و سرویس‌­های اطمینان از سازگاری داده سویفت را اجرا می‌کنند. گره، سرور/ ماشینی است که یکی از فرآیندهای سویفت را اجرا می‌کند. به مجموعه چندین گره که تمامی فرآیندهای مورد نیاز سویفت را اجرا کنند، کلاستر می‌گویند.

در یک کلاستر، گره‌ها به دو گروه منطقی تعلق دارند: منطقه (Region) و ناحیه (Zone). مناطق و نواحی توسط ادمین تعریف می‌شوند و ویژگی‌های منحصربه‌فردی را در مورد مجموعه‌ای از گره‌ها (موقعیت جغرافیایی یا مرز خرابی) مشخص می‌کنند. این‌ نقسیم‌بندی تضمین می‌کند که سویفت داده‌ها را در بخش‌های مختلف کلاستر قرار دهد تا ریسک از دست رفتن داده را کاهش دهد.

مناطق معمولاً شرایطی را نشان می‌دهند که بخش‌هایی از کلاستر از نظر منطقه جغرافیایی جدا هستند. یک کلاستر حداقل یک منطقه دارد و در نتیجه کلاستر‌های تک منطقه‌ای زیادی وجود دارد. کلاستر‌ی که از دو یا چند ناحیه استفاده می‌کند، کلاستر چند منطقه‌ای نام دارد.

هنگامی که یک درخواست خواندن ارسال می‌شود، سرویس پراکسی ابتدا از کپی‌های منطقه خود استفاده مي‌کند، در صورت خلل در دریافت پاسخ، به سراغ مناطق دیگر می‌رود. هنگامی که یک درخواست نوشتن ارسال می‌شود، سرویس پراکسی، به طور پیش فرض، به طور همزمان در همه مکان‌ها می‌نویسد. گزینه ای به نام وابستگی نوشتن وجود دارد که در صورت فعال بودن به کلاستر اجازه می‌دهد، تمام کپی‌ها را در منطقه محلی بنویسد و سپس آنها را به صورت آسنکرون به مناطق دیگر منتقل کند.

در داخل مناطق، سویفت اجازه می‌دهد تا کلاستر را برای جداسازی مرزهای خرابی به کمک تعیین ناحیه پیکربندی کنند. یک ناحیه در دسترس باید توسط مجموعه‌ای متمایز از سخت افزارهای فیزیکی که خرابی آن‌ها از نواحی دیگر جدا می شود، تعریف شود. در یک استقرار مرکز داده واحد، نواحی در دسترس ممکن است رک‌های مختلف باشند. در حالی که باید حداقل یک ناحیه در یک کلاستر وجود داشته باشد، بسیار رایج است که یک کلاستر دارای نواحی متعدد باشد.

سرویس­های اصلی و سروری

چهار فرآیند اصلی و سروری سویفت عبارتند از پراکسی، اکانت، کانتینر و آبجکت. هنگامی که یک گره فقط فرآیند پراکسی‌سرور را اجرا کند، به آن گره پراکسی می‌گویند. گره­‌هایی که یک یا چند از فرآیندهای اصلی دیگر را اجرا کنند (اکانت، کانتینر یا آبجکت)، گره ذخیره­‌سازی نامیده می‌­شوند. گره‌های ذخیره‌سازی حاوی داده‌هایی هستند که درخواست‌های ورودی بر آن‌ها می­تواند تأثیر بگذارند، به عنوان مثال، یک درخواست PUT برای یک شی به گره‌­های دارای فرآیند آبجکت‌سرور که دارای آن شی هستند، می‌­رود.

پراکسی‌سرور تنها درگاه عمومی سویفت است و با کاربران ارتباط برقرار می‌­کند. در نتیجه اولین و آخرین واحدی هستند که به درخواست API رسیدگی می­‌کند. پراکسی‌سرورها از یک معماری غیراشتراکی استفاده می‌­کنند و می‌­توانند بر اساس فشاربار پیش‌بینی شده در صورت نیاز مقیاس شوند. حداقل دو سرور پراکسی باید برای افزونگی مستقر شوند. اگر یکی از سرورهای پراکسی از کار بیافتد، بقیه پراکسی­‌ها سرویس­‌دهی را بر عهده خواهند گرفت.

به عنوان مثال، اگر یک درخواست به سویفت ارسال شود، پراکسی‌سرور درخواست را اعتبارسنجی می‌کند، سپس گره‌های ذخیره‌سازی که مسئول داده‌ هستند (معمولاً سه کپی و رپلیکا از داده در کلاستر موجود است) را بر اساس شناسه شی تعیین می‌کند و درخواست را با ترتیب مشخصی به سرورها ارسال می‌کند. اگر یکی از گره‌های ذخیره‌سازی اصلی در دسترس نباشد، پراکسی یک گره فرعی مناسب دیگر را برای ارسال درخواست انتخاب می‌کند. سپس پراکسی اولین پاسخ دریافتی از گره‌های ذخیره‌سازی را به درخواست کننده برمی­‌گرداند.

اکانت‌سرور به درخواست‌هایی که مربوط به فراداده یک اکانت‌ یا فهرست کانتینرهای اکانت است، رسیدگی می‌کند. این اطلاعات و فراداده‌ها در یک پایگاه داده­ SQLite روی دیسک ذخیره می‌شود.

کانتینرسرور مشابه اکانت‌سرور به درخواست‌های مربوط به فراداده کانتینر یا فهرست اشیاء درون هر کانتینر رسیدگی می‌کند. توجه به این نکته مهم است که لیست اشیاء حاوی اطلاعاتی در مورد مکان شی نیست، صرفاً لیستی از نام اشیاء در یک کانتینر خاص است. مانند اکانت­ها، اطلاعات کانتینر در پایگاه داده SQLite ذخیره می‌­شود.

سرویس آبجکت‌سرور مسئول ذخیره‌­سازی واقعی اشیاء در دیسک‌­های محلی گره خود است. یک شئ به صورت یک فایل­ در دیسک‌­ها در مسیری متشکل از یک پارتیشن مشخص و زمان epoch عملیات، ذخیره می‌شود. براساس زمان epoch است، که کپی‌های مختلف از یک شی در صورت تغییر یک کپی درنهایت با هم سازگار می‌شوند. فراداده شی (سیستمی و سفارشی) در xattrs فایل­‌سیستم در کنار فایل ذخیره می‌شود.

سرویس­های سازگاری و ثبات داده

یکی از جنبه‌های کلیدی سویفت این است که خرابی­‌هایی که رخ می‌­دهد را شناسایی و برای رفع آن­ها اقدام می­‌کند. هنگامی که سرویس‌های اکانت، کانتینر یا آبجکت‌سرور در گره‌ای اجرا می‌شو‌د، به این معنی است که داده در آنجا ذخیره می­‌شود. این بدان معناست که سرویس‌­های سازگاری نیز بر روی آن گره‌­ها اجرا می­‌شود تا از یکپارچگی و در دسترس بودن داده‌ها اطمینان حاصل کند.

آدیتورها در پس‌زمینه هر گره ذخیره‌سازی در یک کلاستر سویفت اجرا می­‌شوند و به طور مداوم دیسک‌ها را اسکن می‌کنند تا مطمئن شوند که داده‌های ذخیره‌شده روی دیسک دچار خرابی بیت یا خرابی سیستم فایل نشده‌ باشند. آدیتورهای اکانت، کانتینر و آبجکت برای پشتیبانی از فرآیند سروری مربوطه خود اجرا می­‌شوند. اگر خطایی پیدا شود، آدیتور شی خراب شده را به یک منطقه قرنطینه منتقل می‌کند.

سرویس‌های رپلیکاتور اکانت، کانتینر و آبجکت در پس‌زمینه همه گره‌هایی که سرویس‌های سروری مربوطه را شامل می‌شوند، اجرا می‌شوند. یک رپلیکاتور به طور مداوم در گره محلی خود اکانت‌ها، کانتینرها یا اشیاء را با کپی‌های موجود در گره‌های دیگر مقایسه می‌کند. اگر یکی از گره‌ها یک کپی قدیمی یا مفقود داشته باشد، آنگاه رپلیکاتور یک کپی از داده‌ محلی خود را به آن گره ارسال می‌کند. رپلیکاتورها فقط داده‌های محلی خود را به گره‌های دیگر منتقل می‌کنند و نه بالعکس.

رپلیکاتور حذف کامل اشیا و کانتینرها را نیز کنترل می‌کند. حذف شی با ایجاد یک فایل سنگ‌قبر صفر بایتی شروع می شود که آخرین نسخه شی است. سپس این نسخه به گره‌های دیگر ارسال می‌شود و شی از کل سیستم حذف می شود. حذف کانتینر فقط با یک کانتینر خالی از شئ امکان پذیر است. در این حالت تگ حذف‌شده بر آن زده می‌شود و رپلیکاتور‌ها دیتابیس کانتینر را حذف می‌کنند.

سرویس کانتینر آپدیتور برای پشتیبانی از اکانت‌ها اجرا می‌شود و مسئول به‌روزرسانی لیست کانتینر در اکانت‌ها و فراداده اکانت از جمله تعداد اشیاء، تعداد کانتینرها و بایت‌های استفاده شده آن اکانت است.

آبجکت آپدیتور برای پشتیبانی از کانتینرها اجرا می‌شود، اما به عنوان یک سرویس اضافی، درواقع سرویس آبجکت سرور بروز کننده اصلی است. تنها در صورتی که تلاش بروزرسانی آبجکت‌سرور ناموفق باشد، آبجکت آپدیتور سپس شروع به بروزرسانی تلاش‌های ناموفق می‌کند و فهرست اشیاء در کانتینر و فراداده کانتینر از قبیل تعداد اشیا و بایت‌هایی استفاده شده آن کانتینر را آپدیت می‌کند.

هنگامی که یک شی با تاریخ انقضا در سیستم نوشته می‌شود، دو اتفاق می افتد، اتفاق اول، زمان انقضا در فراداده شی ذخیره می‌شود، که پس از گذشت آن زمان آبجکت‌سرور دیگر آن را سرویس‌دهی نمی‌کند حتی اگر شی همچنان روی دیسک وجود داشته باشد. اتفاق دوم، یک رفرنس به شی در حال انقضا در یک "اکانت ویژه" ذخیره می‌شود. سرویس آبجکت اکسپایرر به طور دوره‌ای "اکانت ویژه" را برای ارجاع به اشیایی که منقضی شده‌اند، بررسی می‌کند. برای هر شی منقضی‌شده، یک درخواست DELETE صادر می‌کند و داده از کلاستر حذف می‌شود.

سرویس اکانت‌ریپر، اکانت‌هایی که به‌عنوان حذف شده علامت‌گذاری شده اند را شناسایی می‌کند و شروع به حذف تمام اشیاء و کانتینرهای مرتبط با اکانت می‌کند. و تا زمانی که اکانت کاملا خالی و حذف نشود، بکار خود به صورت دوره‌ای ادامه خواهد داد.

نحوه قرارگیری داده در سویفت

هنگامی که سرویس‌های سروری یا سازگاری نیاز به مکان‌یابی داده‌ها دارند، به مکان ذخیره‌سازی (account، account/container/، account/container/object) نگاه می‌کند و یکی از سه حلقه مکانیابی را بررسی می‌کند: حلقه اکانت، حلقه کانتینر یا حلقه آبجکت.

هر حلقه سویفت یک حلقه هش است، که در هر گره کلاستر توزیع می‌شود. نسخه خلاصه شده این است که این حلقه‌ها شامل تعدادی جداول جستجو هستند که سرویس‌های سویفت برای تعیین مکان داده استفاده می‌کنند. این جداول دارای اطلاعات مکان پارتیشن یک شئ بروی دیسک‌های موجود در کلاستر و اطلاعات خود دیسک‌ها از قبیل آدرس، پورت، وزن و ... است.

سویفت داده‌ها را به طور یکنواخت در سراسر کلاستر ذخیره می‌کند تا با سرعت بالایی برای درخواست‌ها در دسترس باشد. هش کردن یک نقش کلیدی در تعیین مکان‌ داده است. هنگامی که یک فرآیند، مانند پراکسی‌سرور، نیاز به یافتن مکان ذخیره داده برای یک درخواست را دارد، به کمک حلقه مناسب هش مکان ذخیره‌سازی را محاسبه می‌کند و مقدار هش را به یک مقدار پارتیشن نگاشت می‌کند. این مقدار هش یکی از صدها یا هزاران مقدار هش خواهد بود که می‌توان هنگام هش کردن مکان‌های ذخیره‌سازی محاسبه کرد.

حلقه هش به تعدادی قسمت خرد می‌شود که هر یک محدوده کوچکی از مقادیر هش مربوط به خود را دریافت می‌کند. این قسمت ها همان پارتیشن‌هایی هستند که در سویفت در مورد آنها صحبت می‌کنیم. پارتیشن‌ها با اندازه یکسان هستند. همانطور که یک حلقه ساخته می‌شود، پارتیشن‌ها به دیسک‌های کلاستر اختصاص داده می‌شوند. این پیاده‌سازی از نظر مفهومی ساده است - یک پارتیشن فقط یک دایرکتوری و مسیر بروی یک دیسک با یک جدول هش مربوط به آنچه شامل می‌شود، می‌باشد.

در حالی که اندازه و تعداد پارتیشن ها تغییر نمی‌کند، تعداد دیسک‌ها در کلاستر تغییر می‌کند. هر چه تعداد دیسک‌ها در یک کلاستر بیشتر باشد پارتیشن‌های هر دیسک کمتر می‌شود. به عنوان مثال ساده، اگر 150 پارتیشن و 2 دیسک وجود داشته باشد، هر دیسک دارای 75 پارتیشن خواهد بود. اگر یک دیسک جدید اضافه شود، هر یک از 3 دیسک 50 پارتیشن خواهند داشت.

پارتیشن‌ها کوچک‌ترین واحدی هستند که سویفت دوست دارد با آن کار کند. داده‌ها به پارتیشن‌ها اضافه می‌شوند، فرآیندهای سازگاری، پارتیشن‌ها را بررسی می‌کنند، پارتیشن‌ها به دیسک‌های جدید منتقل می‌شوند و غیره. با انجام بسیاری از اقدامات در سطح پارتیشن، سویفت می‌تواند ترافیک پردازشی و شبکه را پایین نگه دارد. این بدان معنا است که با افزایش مقیاس سیستم، رفتار همچنان قابل پیش بینی است زیرا تعداد پارتیشن ها ثابت می‌ماند.

دوام و انعطاف پذیری سویفت در برابر خرابی تا حد زیادی به انتخاب تعداد رپلیکا یا نوع erasure coding بستگی دارد. هرچه تعداد کپی‌های بیشتری استفاده شود، محافظت بیشتری در برابر از دست دادن داده‌ها در هنگام خرابی وجود دارد. این امر به ویژه در کلاسترهایی که دارای مراکز داده و مناطق جغرافیایی مجزا برای پخش کردن کپی‌ها در سراسر آنها هستند صادق است.

وقتی می‌گوییم رپلیکاها، منظور پارتیشن‌هایی است که تکرار می‌شوند. معمولا تعداد رپلیکا سه انتخاب می‌شود. در طول ایجاد اولیه حلقه‌های سویفت، هر پارتیشن تکرار می‌شود و هر رپلیکا تا حد امکان در یک مکان منحصر به فرد و دور از بقیه در سراسر کلاستر قرار می‌گیرد. هنگامی که یک دیسک از کار می‌افتد، فرآیندهای رپلیکاتور متوجه می‌شوند و کپی دیگری از داده‌های تحت شعاع قرار گرفته را به مکان‌های موقتی انتقال می‌دهند. احتمال اینکه همه پارتیشن‌ها مربوط به یک رپلیکا در سراسر سیستم خراب شوند (یا از کار بیافتند) قبل از اینکه کلاستر متوجه شود و بتواند داده‌ها را به مکان‌های موقت منتقل کند بسیار کم است، به همین دلیل است که می‌گوییم سویفت بادوام است.

با تعریف پارتیشن‌ها و رپلیکاها، حال می‌توانیم ساختار داده حلقه‌ها را بررسی کنیم. هر یک از حلقه‌های سویفت یک حلقه هش سازگار اصلاح شده است. این ساختار داده حلقه، شامل مقدار شیفت پارتیشن است که سرویس‌ها برای تعیین هش مکان ذخیره‌سازی استفاده می‌کنند. همچنین دارای دو ساختار داده داخلی مهم است: لیست دیسک‌ها و جدول جستجوی دیسک‌ها. لیست دیسک‌ها شامل تمامی دیسک‌هایی است که در هنگام ساخت حلقه اضافه شده‌اند. هر ورودی برای یک دیسک شامل شناسه، منطقه، ناحیه، وزن، IP، پورت و مسیر دیسک است. جدول جستجوی دیسک‌ها دارای یک ردیف برای هر رپلیکا و یک ستون برای هر پارتیشن در کلاستر است. این یک جدولی را ایجاد می کند که معمولاً سه ردیف با هزاران ستون است. در طول ساخت یک حلقه، سویفت بهترین دیسک را برای قراردادن هر کپی پارتیشن با استفاده از وزن‌های دیسک و الگوریتم مکان‌یابی ویژه محاسبه می‌کند. سپس آن دیسک را در جدول ثبت می‌کند.

برای مثال فرآیند پراکسی‌سرور، مقدار هش محل ذخیره‌سازی را که به مقدار پارتیشن نگاشت می‌شود، محاسبه می‌کند. فرآیند پراکسی‌سرور از این مقدار پارتیشن در جدول جستجوی دیسک‌ها استفاده می‌کند. این فرآیند اولین ردیف رپلیکا را در ستون پارتیشن بررسی می‌کند تا شناسه دیسکی که اولین رپلیکا در آن قرار دارد را تعیین کند. این فرآیند دو ردیف بعدی را برای بدست آوردن دو مکان دیگر جستجو می‌کند. در این مثال مقدار پارتیشن 2 است و فرآیند نشان می‌دهد که داده‌ها در دیسک‌های 1، 8 و 10 قرار دارند.

سپس فرآیند پراکسی‌سرور می‌تواند مجموعه دومی از جستجوها را در لیست دیسک‌ها انجام دهد تا اطلاعات مربوط به هر سه دیسک، از جمله شناسه، منطقه، ناحیه، وزن، IP، پورت‌ها و مسیر دیسک را دریافت کند. با این اطلاعات، فرآیند می تواند دیسک‌های مناسب را فراخوانی کند. در شکل زیر، این فرآیند شناسه، منطقه، ناحیه، وزن، IP، پورت و مسیر دیسک برای دستگاه 1 را تعیین کرده است.

برای اطمینان از اینکه کلاستر، داده‌ها را به طور یکنواخت در فضاهای تعریف شده خود (منطقه‌ها، ناحیه‌ها، گره‌ها و دیسک‌ها) ذخیره می‌کند، سویفت با کمک الگوریتم مکان‌یابی Unique as Possible، پارتیشن‌ها را اختصاص می‌دهد. الگوریتم کم استفاده‌شده‌‌ترین و دورترین مکان از کپی‌های دیگر در خوشه را برای قرار دادن پارتیشن‌ها شناسایی می‌کند. ابتدا به دنبال کم استفاده‌ترین منطقه می‌گردد، اگر همه مناطق دارای یک پارتیشن باشند، سپس به دنبال ناحیه کمتر استفاده شده، سپس سرور و در نهایت دیسک کم استفاده‌شده‌تر می‌گردد و پارتیشن را در آنجا قرار می‌دهد. این الگوریتم همچنین تلاش می‌کند تا کپی‌های پارتیشن را تا حد امکان دور از یکدیگر قرار دهد. هنگامی که سویفت محل قرارگیری همه پارتیشن‌ها را محاسبه و ثبت کرد، حلقه آماده ساخته شدن است.