Bagikan melalui

Arsitektur serta skenario dengan ketersediaan tinggi untuk SAP NetWeaver

  • Artikel

Definisi terminologi

Ketersediaan tinggi: Mengacu pada kumpulin teknologi yang meminimalkan gangguan IT dengan menyediakan kelangsungan bisnis layanan IT melalui komponen yang redundan, toleran terhadap kesalahan, atau dilindungi kegagalan di dalam pusat data sama. Dalam kasus kami, pusat data berada dalam satu wilayah Azure.

Pemulihan bencana: Juga mengacu pada meminimalkan gangguan layanan IT dan pemulihannya, tetapi di berbagai pusat data yang mungkin berjarak ratusan mil dari satu sama lain. Dalam kasus kami, pusat data mungkin berada di berbagai wilayah Azure dalam wilayah geopolitik yang sama atau di lokasi yang ditetapkan oleh Anda sebagai pelanggan.

Gambaran umum ketersediaan tinggi

Ketersediaan tinggi SAP di Azure dapat dipisahkan menjadi tiga jenis:

  • Ketersediaan tinggi infrastruktur Azure:

    Misalnya, ketersediaan tinggi dapat mencakup komputasi (VM), jaringan, atau penyimpanan dan manfaatnya untuk meningkatkan ketersediaan aplikasi SAP.

  • Menggunakan mulai ulang VM infrastruktur Azure untuk melindungi aplikasi SAP:

    Jika Anda memutuskan untuk tidak menggunakan fungsionalitas seperti Windows Server Failover Clustering (WSFC) atau Pacemaker di Linux, pemulaian ulang Azure VM digunakan. Ini memulihkan fungsionalitas dalam sistem SAP jika ada waktu henti yang direncanakan dan tidak direncanakan dari infrastruktur server fisik Azure dan platform Azure yang mendasarinya secara keseluruhan.

  • Ketersediaan tinggi aplikasi SAP:

    Untuk mencapai ketersediaan tinggi sistem SAP penuh, Anda harus melindungi semua komponen sistem SAP yang penting. Contohnya:

    • Server aplikasi SAP berlebihan.
    • Komponen unik. Contohnya mungkin komponen titik kegagalan tunggal (SPOF), seperti instans SAP ASCS/SCS atau sistem manajemen basis data (DBMS).

Ketersediaan tinggi SAP di Azure berbeda dari ketersediaan tinggi SAP di lingkungan fisik atau virtual secara lokal.

Tidak ada konfigurasi ketersediaan tinggi SAP yang terintegrasi dengan sapinst untuk Linux karena ada untuk Windows. Untuk informasi tentang SAP ketersediaan tinggi di lingkungan lokal untuk Linux, lihat Informasi mitra ketersediaan tinggi.

Ketersediaan tinggi infrastruktur Azure

SLA untuk komputer virtual instans tunggal

Saat ini ada SLA VM tunggal sebesar 99,9% dengan penyimpanan premium. Untuk mendapatkan gambaran tentang ketersediaan VM tunggal, Anda dapat membuat produk dari berbagai Perjanjian Tingkat Layanan Azure yang tersedia.

Dasar perhitungannya adalah 30 hari per bulan, atau 43.200 menit. Misalnya, waktu henti 0,05% sama dengan 21,6 menit. Seperti biasa, ketersediaan berbagai layanan dihitung dengan cara berikut:

(Layanan Ketersediaan #1/100) x (Layanan Ketersediaan #2/100) x (Layanan Ketersediaan #3/100) *...

Contohnya:

(99,95/100) x (99,9/100) x (99,9/100) = 0,9975 atau ketersediaan keseluruhan 99,75%.

Beberapa instans komputer virtual dalam kumpulan ketersediaan yang sama

Untuk semua komputer virtual yang memiliki dua instans atau lebih yang disebarkan dalam set ketersediaan yang sama, kami menjamin bahwa Anda memiliki konektivitas komputer virtual ke setidaknya satu instans setidaknya 99,95% dari waktu.

Ketika dua atau beberapa VM merupakan bagian dari kumpulan ketersediaan yang sama, setiap komputer virtual dalam kumpulan ketersediaan ditetapkan sebagai domain pembaruan dan domain kesalahan oleh platform Azure yang mendasarinya.

  • Domain pembaruan menjamin bahwa beberapa VM tidak di-boot ulang secara bersamaan selama pemeliharaan infrastruktur Azure yang direncanakan. Hanya satu VM yang di-boot ulang pada satu waktu.
  • Domain kesalahan menjamin bahwa VM disebarkan pada komponen perangkat keras yang tidak berbagi sumber daya umum dan sakelar jaringan. Saat server, sakelar jaringan, atau sumber daya mengalami waktu henti yang tidak direncanakan, hanya satu VM yang terpengaruh.

Untuk informasi selengkapnya, lihat mengelola ketersediaan komputer virtual di Azure menggunakan set ketersediaan.

Azure Availability Zone

Azure sedang dalam proses meluncurkan konsep Zona Ketersediaan Azure di seluruh Wilayah Azure yang berbeda. Di wilayah Azure tempat Zona Ketersediaan ditawarkan, wilayah Azure memiliki beberapa pusat data, yang independen dalam memasok sumber daya, pendinginan, dan jaringan. Alasan menawarkan zona berbeda dalam satu wilayah Azure adalah untuk memungkinkan Anda menyebarkan aplikasi di dua atau tiga Zona Ketersediaan yang ditawarkan. Dengan asumsi bahwa masalah di sumber daya dan/atau jaringan hanya akan memengaruhi satu infrastruktur Zona Ketersediaan, penerapan aplikasi Anda dalam wilayah Azure masih berfungsi penuh. Akhirnya dengan beberapa pengurangan kapasitas karena beberapa VM dalam satu zona mungkin hilang. Tetapi VM di dua zona lainnya masih aktif dan berjalan. Wilayah Azure yang menawarkan zona tercantum di Zona Ketersediaan Azure.

Saat menggunakan Zona Ketersediaan, ada beberapa hal yang perlu dipertimbangkan. Daftar pertimbangan seperti:

  • Anda tidak dapat menyebarkan Kumpulan Ketersediaan Azure dalam Zona Ketersediaan. Satu-satunya kemungkinan untuk menggabungkan Set ketersediaan dan Zona Ketersediaan adalah dengan grup penempatan kedekatan. Untuk informasi selengkapnya, lihat artikel Menggabungkan set ketersediaan dan zona ketersediaan dengan grup penempatan kedekatan.
  • Anda tidak dapat menggunakan Load Balancer Dasar untuk membuat solusi kluster failover berdasarkan Windows Failover Cluster Services atau Linux Pacemaker. Sebagai gantinya , Anda perlu menggunakan SKU Azure Standard Load Balancer.
  • Zona Ketersediaan Azure tidak memberikan jaminan jarak tertentu antara zona yang berbeda dalam satu wilayah.
  • Latensi jaringan antara Zona Ketersediaan Azure yang berbeda dalam wilayah Azure yang berbeda mungkin berbeda dari wilayah Azure ke wilayah. Akan ada kasus, di mana Anda sebagai pelanggan dapat secara wajar menjalankan lapisan aplikasi SAP yang disebarkan di berbagai zona karena latensi jaringan dari satu zona ke VM DBMS aktif masih dapat diterima dari dampak proses bisnis. Sedangkan mungkin ada skenario pelanggan di mana latensi antara DBMS VM aktif dalam satu zona dan instans aplikasi SAP di VM di zona lain bisa terlalu mengganggu dan tidak dapat diterima untuk proses bisnis SAP. Akibatnya, arsitektur penyebaran harus berbeda dengan arsitektur aktif/aktif untuk aplikasi atau arsitektur aktif/pasif jika latensi terlalu tinggi.
  • Menggunakan disk terkelola Azure wajib untuk disebarkan ke Zona Ketersediaan Azure.

Virtual Machine Scale Set dengan Flexible Orchestration

Di Azure, Virtual Machine Scale Sets dengan orkestrasi Fleksibel menawarkan sarana untuk mencapai ketersediaan tinggi untuk beban kerja SAP, sama seperti kerangka kerja penyebaran lainnya seperti set ketersediaan dan zona ketersediaan. Dengan set skala yang fleksibel, VM dapat didistribusikan di berbagai zona ketersediaan dan domain kesalahan, menjadikannya opsi yang cocok untuk menyebarkan beban kerja SAP yang sangat tersedia.

Set skala komputer virtual dengan orkestrasi fleksibel menawarkan fleksibilitas untuk membuat set skala dalam wilayah atau menjangkaunya di seluruh zona ketersediaan. Saat membuat, skala fleksibel yang ditetapkan dalam wilayah dengan platformFaultDomainCount>1 (FD>1), VM yang disebarkan dalam set skala akan didistribusikan di sejumlah domain kesalahan tertentu di wilayah yang sama. Di sisi lain, membuat skala fleksibel yang ditetapkan di seluruh zona ketersediaan dengan platformFaultDomainCount=1 (FD=1) akan mendistribusikan VM di berbagai zona dan set skala juga akan mendistribusikan VM di berbagai domain kesalahan dalam setiap zona berdasarkan upaya terbaik. Untuk beban kerja SAP hanya set skala fleksibel dengan FD=1 yang didukung.

Keuntungan menggunakan set skala fleksibel dengan FD=1 untuk penyebaran lintas zona, alih-alih penyebaran zona ketersediaan tradisional adalah bahwa VM yang disebarkan dengan set skala akan didistribusikan di berbagai domain kesalahan dalam zona dengan cara upaya terbaik. Untuk menghindari keterbatasan yang terkait dengan pemanfaatan grup penempatan kedekatan untuk memastikan ketersediaan VM di semua pusat data Azure atau di bawah setiap tulang belakang jaringan, disarankan untuk menyebarkan beban kerja SAP di seluruh zona ketersediaan menggunakan set skala fleksibel dengan FD=1. Strategi penyebaran ini memastikan bahwa VM yang disebarkan di setiap zona tidak dibatasi untuk satu pusat data atau tulang belakang jaringan, dan semua komponen sistem SAP, seperti database, ASCS/ERS, dan tingkat aplikasi tercakup pada tingkat zonal.

Jadi, untuk penyebaran beban kerja SAP baru di seluruh zona ketersediaan, kami menyarankan untuk menggunakan set skala fleksibel dengan FD=1. Untuk informasi selengkapnya, lihat set skala komputer virtual untuk dokumen beban kerja SAP.

Pemeliharaan komputer virtual yang terencana dan tidak terencana

Dua jenis peristiwa platform Azure dapat memengaruhi ketersediaan komputer virtual Anda:

  • Peristiwa Pemeliharaan terencana adalah pembaruan berkala yang dibuat oleh Microsoft untuk platform Azure yang mendasarinya. Pembaruan meningkatkan keandalan, performa, dan keamanan keseluruhan infrastruktur platform yang dijalankan oleh komputer virtual Anda.
  • Peristiwa Pemeliharaan tidak terencana terjadi saat perangkat keras atau infrastruktur fisik yang mendasari komputer virtual Anda gagal dalam beberapa hal. Peristiwa ini mungkin termasuk kegagalan jaringan lokal, kegagalan disk lokal, atau kegagalan tingkat rak lainnya. Ketika kegagalan tersebut terdeteksi, platform Azure secara otomatis memigrasikan komputer virtual Anda dari server fisik tidak sehat yang menghosting komputer virtual Anda ke server fisik yang sehat. Peristiwa seperti itu jarang terjadi, tetapi mungkin juga menyebabkan komputer virtual Anda melakukan boot ulang.

Untuk informasi selengkapnya, lihat pemeliharaan komputer virtual di Azure.

Redundansi Azure Storage

Data di akun penyimpanan Anda selalu direplikasi untuk memastikan ketahanan dan ketersediaan tinggi, memenuhi SLA Azure Storage bahkan dalam menghadapi kegagalan perangkat keras sementara.

Karena Azure Storage menyimpan tiga gambar data secara default, penggunaan RAID 5 atau RAID 1 di beberapa disk Azure tidak diperlukan.

Untuk informasi selengkapnya, lihat Replikasi Azure Storage.

Azure Managed Disks

Disk Terkelola adalah jenis sumber daya di Azure Resource Manager, adalah opsi penyimpanan yang direkomendasikan alih-alih hard disk virtual (VHD) yang disimpan di akun penyimpanan Azure. Disk terkelola secara otomatis selaras dengan set ketersediaan Azure dari komputer virtual yang dilampirkan. Disk terkelola meningkatkan ketersediaan komputer virtual Anda dan layanan yang berjalan di dalamnya.

Untuk informasi selengkapnya, lihat gambaran umum Disk Terkelola Azure.

Sebaiknya Anda menggunakan disk terkelola karena disk terkelola tersebut menyederhanakan penyebaran dan manajemen komputer virtual Anda.

Perbandingan jenis penyebaran yang berbeda untuk beban kerja SAP

Berikut adalah ringkasan cepat dari berbagai jenis penyebaran yang tersedia untuk beban kerja SAP.

Fitur Virtual Machine Scale Set dengan Flexible Orchestration (FD=1) Zona Ketersediaan Kumpulan Ketersediaan
Perilaku penyebaran Instans mendarat di 1, 2, atau 3 zona ketersediaan dan didistribusikan di berbagai rak dalam setiap zona berdasarkan upaya terbaik Instans mendarat di 1, 2, atau 3 zona ketersediaan Instans mendarat di dalam wilayah dan didistribusikan di berbagai domain kesalahan/pembaruan
Menetapkan VM dan disk terkelola ke zona Ketersediaan tertentu Ya Ya Tidak
Domain kesalahan - Penyebaran maks (Azure akan menyebarkan instans secara maksimal) Ya Tidak Ya, berdasarkan jumlah domain kesalahan yang ditentukan selama pembuatan.
Menghitung ke perataan domain kesalahan penyimpanan Tidak No Ya
Reservasi Kapasitas Ya (tetapkan reservasi kapasitas di tingkat VM) Ya Tidak

Catatan

Opsi penyebaran ketersediaan tinggi untuk beban kerja SAP

Saat menyebarkan beban kerja SAP ketersediaan tinggi di Azure, penting untuk mempertimbangkan berbagai jenis penyebaran yang tersedia, dan bagaimana mereka dapat diterapkan di berbagai wilayah Azure (seperti di seluruh zona, dalam satu zona, atau di wilayah tanpa zona). Tabel berikut mengilustrasikan beberapa opsi ketersediaan tinggi untuk sistem SAP di wilayah Azure.

Jenis sistem Di berbagai zona di suatu wilayah Di zona bernyanyi dari suatu wilayah Di wilayah tanpa zona
Sistem SAP Ketersediaan Tinggi Set skala fleksibel dengan FD=1 Set Ketersediaan dengan Grup Penempatan Kedekatan Set Ketersediaan
Set Ketersediaan dan Zona Ketersediaan dengan Grup Penempatan Kedekatan Set skala fleksibel dengan FD=1 (pilih hanya satu zona) Set skala fleksibel dengan FD=1 (tidak ada zona yang ditentukan)
Zona Ketersediaan Set Ketersediaan
  • Penyebaran di berbagai zona di suatu wilayah: Untuk ketersediaan tertinggi, sistem SAP harus disebarkan di berbagai zona di suatu wilayah. Ini memastikan bahwa jika satu zona tidak tersedia, sistem SAP terus tersedia di zona lain. Jika Anda menyebarkan beban kerja SAP baru di seluruh zona ketersediaan, disarankan untuk menggunakan skala komputer virtual fleksibel yang diatur dengan opsi penyebaran FD=1. Ini memungkinkan Anda untuk menyebarkan beberapa VM di berbagai zona di suatu wilayah tanpa khawatir tentang batasan kapasitas atau grup penempatan. Kerangka kerja set skala memastikan bahwa VM yang disebarkan dengan set skala akan didistribusikan di berbagai domain kesalahan dalam zona dengan cara upaya terbaik. Semua komponen SAP dengan ketersediaan tinggi seperti SAP ASCS/ERS, database SAP didistribusikan di berbagai zona, sedangkan beberapa server aplikasi di setiap zona didistribusikan ke berbagai domain kesalahan berdasarkan upaya terbaik.
  • Penyebaran di satu zona wilayah: Untuk menyebarkan sistem SAP ketersediaan tinggi Anda secara regional di lokasi dengan beberapa zona ketersediaan, dan jika penting bagi semua komponen sistem untuk berada dalam satu zona, maka disarankan untuk menggunakan Set Ketersediaan dengan opsi penyebaran Grup Penempatan Kedekatan. Pendekatan ini memungkinkan Anda mengelompokkan semua komponen sistem SAP dalam satu zona ketersediaan, memastikan bahwa komputer virtual dalam set ketersediaan tersebar di berbagai domain kesalahan dan pembaruan. Meskipun penyebaran ini menyelaraskan komputasi ke domain kesalahan penyimpanan, kedekatan tidak dijamin. Namun, karena opsi penyebaran ini bersifat regional, opsi ini tidak mendukung Azure Site Recovery untuk pemulihan bencana zona-ke-zona. Selain itu, opsi ini membatasi seluruh penyebaran SAP ke satu pusat data, yang dapat menyebabkan keterbatasan kapasitas jika Anda perlu mengubah ukuran SKU atau menskalakan instans aplikasi.
  • Penyebaran di wilayah tanpa zona: Jika Anda menyebarkan sistem SAP di wilayah yang tidak memiliki zona apa pun, disarankan untuk menggunakan Set ketersediaan. Opsi ini menyediakan redundansi dan toleransi kesalahan dengan menempatkan VM di domain kesalahan yang berbeda dan memperbarui domain.

Penting

Perlu dicatat bahwa opsi penyebaran untuk wilayah Azure hanyalah saran. Strategi penyebaran yang paling cocok untuk sistem SAP Anda akan bergantung pada persyaratan dan lingkungan khusus Anda.

Memanfaatkan infrastruktur Azure dengan ketersediaan tinggi untuk melindungi aplikasi SAP

Jika Anda memutuskan untuk tidak menggunakan fungsionalitas seperti WSFC atau Pacemaker di Linux (didukung untuk SUSE Linux Enterprise Server 12 dan yang lebih baru, dan Red Hat Enterprise Linux 7 dan yang lebih baru), mulai ulang Azure VM digunakan. Ini memulihkan fungsionalitas dalam sistem SAP jika ada waktu henti yang direncanakan dan tidak direncanakan dari infrastruktur server fisik Azure dan platform Azure yang mendasarinya secara keseluruhan.

Untuk informasi selengkapnya tentang pendekatan ini, lihat Memanfaatkan mulai ulang VM infrastruktur Azure untuk mencapai ketersediaan sistem SAP yang lebih tinggi.

Ketersediaan tinggi aplikasi SAP di Azure IaaS

Untuk mencapai ketersediaan tinggi sistem SAP penuh, Anda harus melindungi semua komponen sistem SAP yang penting. Contohnya:

  • Server aplikasi SAP berlebihan.
  • Komponen unik. Contohnya mungkin komponen titik kegagalan tunggal (SPOF), seperti instans SAP ASCS/SCS atau sistem manajemen basis data (DBMS).

Bagian selanjutnya membahas bagaimana mencapai ketersediaan tinggi untuk ketiga komponen sistem SAP yang penting.

Arsitektur ketersediaan tinggi untuk server aplikasi SAP

Logo Windows. Windows dan Logo Linux. Linux

Anda biasanya tidak memerlukan solusi ketersediaan tinggi khusus untuk server aplikasi SAP dan instans dialog. Anda mencapai ketersediaan tinggi dengan redundansi, dan Anda mengonfigurasi beberapa contoh dialog dalam berbagai contoh komputer virtual Azure. Anda harus memiliki setidaknya dua instans aplikasi SAP yang terinstal di dua instans komputer virtual Azure.

Bergantung pada jenis penyebaran (set skala fleksibel dengan FD=1, zona ketersediaan atau set ketersediaan), Anda harus mendistribusikan instans server aplikasi SAP yang sesuai untuk mencapai redundansi.

  • Set skala fleksibel dengan platformFaultDomainCount=1 (FD=1): Server aplikasi SAP yang disebarkan dengan set skala fleksibel (FD=1) mendistribusikan komputer virtual di berbagai zona ketersediaan dan set skala juga akan mendistribusikan VM di berbagai domain kesalahan di setiap zona berdasarkan upaya terbaik. Ini memastikan bahwa jika satu zona tidak tersedia, server aplikasi SAP yang disebarkan di zona lain terus tersedia.
  • Zona ketersediaan: Server aplikasi SAP yang disebarkan di seluruh zona ketersediaan memastikan bahwa VM tersebar di berbagai zona untuk mencapai redundansi. Ini memastikan bahwa jika satu zona tidak tersedia, server aplikasi SAP yang disebarkan di zona lain terus tersedia. Untuk informasi selengkapnya, lihat Konfigurasi beban kerja SAP dengan Zona Ketersediaan Azure
  • Set ketersediaan: Server aplikasi SAP yang disebarkan dalam set ketersediaan memastikan bahwa VM didistribusikan di berbagai domain kesalahan dan domain pembaruan. Saat menempatkan VM di berbagai domain pembaruan, pastikan bahwa VM tidak diperbarui pada saat yang sama selama waktu henti pemeliharaan terencana. Sedangkan, menempatkan VM di domain kesalahan yang berbeda memastikan bahwa VM dilindungi dari kegagalan perangkat keras atau gangguan daya dalam pusat data. Tetapi jumlah domain kesalahan dan pembaruan yang dapat Anda gunakan di set ketersediaan Azure dalam unit skala Azure terbatas. Jika Anda terus menambahkan VM ke satu set ketersediaan, dua atau beberapa VM pada akhirnya akan berakhir di domain kesalahan atau pembaruan yang sama. Untuk informasi selengkapnya, lihat bagian Kumpulan ketersediaan Azure dari perencanaan dan implementasi komputer virtual Azure untuk dokumen SAP NetWeaver.

Hanya disk yang tidak dikelola: Saat menggunakan disk yang tidak dikelola dengan set ketersediaan, penting untuk mengenali bahwa akun penyimpanan Azure menjadi satu titik kegagalan. Oleh karena itu, sangat penting untuk memposisikan minimal dua akun penyimpanan Azure, di mana setidaknya dua komputer virtual didistribusikan. Dalam pengaturan yang ideal, disk dari setiap mesin virtual yang menjalankan instance dialog SAP akan digunakan di akun penyimpanan yang berbeda.

Penting

Sebaiknya Anda menggunakan disk terkelola Azure untuk penginstalan ketersediaan tinggi SAP Anda. Karena disk terkelola secara otomatis disejajarkan dengan kumpulan ketersediaan komputer virtual yang dilampirkan, disk tersebut meningkatkan ketersediaan komputer virtual Anda dan layanan yang berjalan di dalamnya.

Arsitektur dengan ketersediaan tinggi untuk instans SAP ASCS/SCS di Windows

Logo Windows. Windows

Anda dapat menggunakan solusi WSFC untuk melindungi instans SAP ASCS/SCS. Berdasarkan jenis konfigurasi berbagi kluster (berbagi file atau disk bersama), Anda dapat merujuk ke solusi yang sesuai berdasarkan jenis penyimpanan Anda.

Arsitektur ketersediaan tinggi untuk instans SAP ASCS/SCS di Linux

Logo Linux. Linux

Di Linux, konfigurasi pengklusteran instans SAP ASCS/SCS tergantung pada distribusi sistem operasi dan jenis penyimpanan yang digunakan. Disarankan untuk menerapkan solusi yang sesuai sesuai dengan kerangka kerja kluster OS spesifik Anda.

Konfigurasi multi-SID SAP NetWeaver untuk instans SAP ASCS/SCS yang berkluster

Logo Windows. Jendela

Multi-SID didukung dengan WSFC, menggunakan berbagi file dan disk bersama. Untuk informasi selengkapnya tentang arsitektur ketersediaan tinggi multi-SID di Windows, lihat:

Logo Linux. Linux

Pengklusteran multi-SID didukung pada kluster Linux Pacemaker untuk SAP ASCS/ERS, terbatas pada lima SAP SID pada kluster yang sama. Untuk informasi selengkapnya tentang arsitektur ketersediaan tinggi multi-SID di Linux, lihat:

Ketersediaan tinggi instans DBMS

Dalam sistem SAP, server DBMS juga sebagai titik kegagalan tunggal. Jadi, penting untuk melindungi database dengan menerapkan solusi ketersediaan tinggi. Solusi ketersediaan tinggi DBMS bervariasi berdasarkan database yang digunakan untuk sistem SAP. Berdasarkan database Anda, ikuti panduan untuk mencapai ketersediaan tinggi pada database Anda.

Database Rekomendasi DR
SAP HANA Replikasi Sistem HANA (HSR)
Oracle Oracle Data Guard
IBM DB2 Pemulihan bencana ketersediaan tinggi (HADR)
Microsoft SQL Microsoft SQL Always On
SAP ASE ASE HADR Selalu Aktif